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SUMMARY 


BACKGROUND 

This  document  is  the  Phase  I  Pinal  Report  for  research  conducted 
by  Technology  Applications,  Inc.  (TAI)  under  the  Department  of 
Defense  (DOD)  contract  number  DAAK70-87-C0058 ,  entitled 
"Intelligent  LOAD  MANager  ( LOADMAN ) . "  This  project  was  funded  as 
a  part  of  the  Small  Business  Innovation  Research  (SBXR)  program 
and  is  a  feasibility  study  aimed  at  using  artificial  intelligence 
(AI)  techniques  to  explore  the  implementation  of  an  expert  system 
serving  as  an  intelligent  power  systems  manager.  In  developing 
the  demonstration  prototype,  the  emphasis  was  placed  on  clarity 
and  the  use  of  generic  techniques  which  would  allow  future 
extensions  and  modifications.  Phase  I  was  comprised  of  four 
tasks s 

1)  Develop  Knowledge  Representation (s) 

2)  Develop  Reasoning  Mechanism 

3)  Develop  Demonstration  Prototype 

4)  Project  Management  and  Documentation 

Tasks  1  and  2  involved  detailed  domain  analysis,  evaluation  of 
the  prospects  of  an  expert  system  in  this  domain,  and  the  steps 
that  should  be  taken  to  make  further  development  of  the  load 
management  system  a  success.  Task  3  involved  the  implementation 
of  various  parts  of  the  system  to  demonstrate  the  feasibility  of 
using  AI  techniques  to  solve  relevant  problems.  Task  4  involved 
the  production  of  this  report  which  has  been  written  with  an 
emphasis  on  domain  analysis  and  future  development  strategies. 


Task  1  -  Developing  Knowledge  Reoresentationfs) 

Work  on  this  task  started  with  discussions  (both  internal  and 
with  Army  personnel  at  Ft.  Belvoir)  of  the  kind  of  problems  that 
the  Army  would  like  to  solve.  The  various  physical  objects  in  the 
domain  and  their  characteristics  were  discussed  (e.g., 
generators,  telephones,  radio  communications  equipment, 
distribution  equipment,  etc.).  Future  extensions  to  the  system  to 
make  it  handle  other  problems  were  also  discussed  so  that  the 
knowledge  representation  could  be  designed  on  a  generic  and  broad 
basis. 

A  classical  object-oriented  knowledge  base  (i.e.,  objects/ slots/ 
facets)  was  chosen  to  represent  data  about  the  mission  and 
declarative  knowledge  about  the  various  loads,  sources,  and 
distributors.  In  other  words,  all  entities  in  the  problem  domain 
are  represented  using  objects.  This  has  the  advantages  of 
modularity,  conciseness,  and  natural  representation.  Also,  an 
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object-oriented  representation  allows  extensions  to  be  made 
easily  and  naturally. 


laaK  2.-  Bflgfllflttlng  the  Reasoning  .Mechanism 

Various  example  problems  and  relevant  solution  methods  were  used 
to  consider  different  reasoning  mechanisms.  The  general  problem 
is  one  of  system  configuration  and  loading  within  a  set  of 
constraints.  The  nature  of  the  solution  is  iterative,  so  part  of 
the  reasoning  mechanism  is  better  implemented  using  conventional 
LISP  code.  However,  for  the  system  to  be  generic  and  extendible, 
rule-based  reasoning  is  a  must.  Thus,  a  combination  of 
conventional  programming  and  rules  is  used  to  represent  and 
process  the  various  constraints.  For  example,  there  are  placement 
constraints  which  specify  some  undesired  positional  relationships 
between  two  camp  objects  or  undesired  location  of  objects  with 
respect  to  the  camp  layout. 


Task  3 -Developing  the  Demonstration  Prototype 

A  demonstration  prototype  was  built  during  the  course  of  the 
project  to  explore  further  the  teohnical  feasibility  and 
practicality  of  the  chosen  AI  techniques.  In-house  examples  and 
test  cases  were  used  to  develop  and  test  various  parts  of  the 
prototype.  This  effort  helped  the  project  team  appreciate  the 
need  for  accurate  data  in  terms  of  the  equipment  used  and  also  in 
terms  of  the  Army's  priorities,  policies,  and  procedures.  The 
unavailability  of  knowledge/ data  regarding  the  Army's  power 
generation/distribution  planning  and  decision  making  is  the  main 
concern  that  has  arisen  out  of  the  prototype  development  effort. 
However,  the  prototype  demonstrates  convincingly,  with  well- 
chosen  examples  and  reasonable  assumptions  (where  there  were  gaps 
in  the  knowledge) ,  that  an  expert  system  could  be  built  to  solve 
the  load  management  problems  in  a  military  setting. 


laaK-A-j-  Prelect. Management  anti  pggvunsntatign 

The  project  report  was  prepared  with  an  emphasis  on  establishing 
the  general  philosophy  and  feasibility  of  the  idea.  Shortcomings 
of  the  present  methods  and  equipment  have  been  clearly  pointed 
out.  Ways  to  handle  these  problems  and  future  development  of  the 
distribution  system  have  been  suggested.  The  final  report  begins 
with  an  analysis  of  the  domain  and  assessment  of  its  suitability 
for  an  expert  system.  Then  the  conceptual  system  design  of  the 
Phase  II  implementation  is  discussed.  It  is  recommended  that  this 
be  carried  out  in  two  stages  -  as  an  off-line  advisory  system  and 
then  an  extension  of  such  a  system  into  an  on-line  autonomous 
system.  The  next  section  contains  the  description  of  the 
demonstration  prototype.  This  is  followed  by  the  project 
conclusions  and  recommendations. 
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SUMMARY  CONCLUSIONS  AND  RECOMMENDATIONS 

Domain  analysis  and  tha  davalopmant  of  tha  rapid  prototype  system 
have  revealed  that  the  implementation  of  an  expert  system  is 
^„indeed> possible  if  some  preliminary  work  is  done  to  standardize 
^  the  equipment  and  establish  clear  guidelines  for  load  shedding 
and  other  decisions.  This  effort  should  be  carried  out  (even  if 
the  expert  system  is  not  implemented)  to  ensure  reliable, 
efficient  power  generation  and  utilization  and  to  reduce  the 
likelihood  of  costly  mistakes .  a  -TAT  is  convinced  that  the 
technology  is  valuable  to  the  Army  \in  terms  of  improved  inventory 
handling,  optimized  power  usage,';  and  operator  training,  all 


leading  to  more  effective  mission  completion,  ri(| 
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SECTION  1 


INTRODUCTION 


1 . 1  BACKGROUND 

This  document  is  the  Phase  I  Final  Report  for  research  conducted 
by  Technology  Applications,  Inc.  (TAI)  under  the  Department  of 
Defense  (DOD)  contract  number  DAAK7 0-87-00058,  entitled 
"Intelligent  LOAD  MANager  (LOADMAN)."  This  pro j eat  was  funded  as 
a  part  of  the  Small  Business  Innovation  Research  (SBIR)  program 
and  is  a  feasibility  study  aimed  at  using  artificial  intelligence 
(AI)  techniques  to  explore  the  implementation  of  an  expert  system 
serving  as  an  intelligent  power  systems  manager.  This 
investigation  addresses  both  planning  issues  (e.g.,  power 
generation/distribution,  logistics,  and  supply)  and  tactical 
issues  (e.g.,  campsite  power  distribution  layout  and  proper  load 
shedding  fo] lowing  a  generator  casualty) . 

Military  units  are  heavily  dependent  on  eleotrio  power  which  is 
normally  provided  by  diesel  or  gasoline  generators.  The  critical 
nature  of  the  environment  calls  for  a  Power  Generation  and 
Distribution  system  which  is  highly  flexible  and  reliable.  The 
power  should  be  distributed  and  used  efficiently,  and  the 
equipment  requirements  must  be  minimized  so  that  the  logistics 
burden  is  reduced. 


1.2  PROJECT  OBJECTIVES 

The  objective  of  this  project/report  is  to  explore  the  idea  of 
using  new  (expert  system)  computer  technology  in  this  domain, 
thereby  facilitating  the  application  of  load  management 
techniques  to  perform  various  functions  like  load  shedding  and 
duty  cycle  scheduling.  This  controlling  system  should  be  designed 
so  that  it  does  not  totally  break  down  under  adverse  conditions. 
Instead  it  should  be  able  to  maintain  a  level  of  performance  that 
is  as  good  as  the  operating  conditions  will  allow.  Since  the 
system  has  to  optimize  power  utilization  in  degrading 
circumstances,  it  will  have  to  drop  loads  and/or  operate  some 
loads  at  reduced  power.  Such  decisions  are  important  because  they 
can  affect  the  success  of  the  mission.  So  the  system  will  have  to 
be  designed  according  to  well-defined  Army  policies  and 
procedures . 
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1.3  GENERAL  PROJECT  COURSE  CHANGES 


The  project  work  started  with  a  discussion  of  the  kind  of 
problems  that  the  Army  would  like  to  solve.  At  this  time,  the 
Army  contact  personnel  indicated  that  the  system  be  designed 
initially  as  an  off-line  advisory  system  because  of  the 
additional  cost  of  installing  sensors  and  control  equipment  to 
the  power  equipment.  The  system  possibly  could  be  converted  to  an 
on-line  autonomous  system  in  a  later  phase.  It  was  decided  that 
the  system  should  be  designed  as  a  constraint  representation  and 
management  system  that  would  be  sufficiently  generic  so  that  it 
can  be  expanded  to  include  other  applications.  A  literature 
survey  was  then  performed  to  study  other  systems  that  tackled 
similar  problems.  Even  though  these  systems  were  not  generic 
enough  for  direct  application,  they  provided  numerous  pointers 
that  helped  in  developing  suitable  knowledge  representation  and 
generic  scheduling  techniques. 

The  implementation  of  the  Demonstration  Prototype  was  then  begun. 
In-house  examples  and  test  cases  were  used  to  develop  and  test 
various  parts  of  the  prototype.  The  prototype  had  some  gaps  in 
its  knowledge  about  the  domain  because  of  the  absence  of  "real" 
experts  who  understood  and  knew  how  to  solve  these  problems. 
Sufficiently  accurate  test  cases  were  not  available  and  it  became 
very  difficult  to  proaeed  with  the  completion  of  the  prototype. 

At  this  stage,  the  project  team  was  informed  that  a  demonstration 
proving  that  advanced  computer  techniques  could  be  used  to  solve 
load  management  problems  was  all  that  was  expected  of  this  phase 
of  the  project.  The  project  team  then  proceeded  to  identify  and 
document  the  missing  knowledge  elements  in  the  problem  domain  and 
the  various  steps  that  should  be  taken  to  ensure  that  the 
successful  development  of  an  expert  system  was  indeed  possible. 


1.4  REPORT  ORGANIZATION 

The  rest  of  the  report  is  organized  as  follows.  Section  2 
discusses  the  problem  domain,  its  limitations,  and  its 
suitability  for  an  expert  system  under  current  conditions.  It 
also  recommends  issues  to  be  analyzed  and  steps  that  should  be 
taken  to  standardize  the  domain  to  the  point  where  the  knov/ledge 
is  complete  enough  for  incorporation  in  an  expert  system.  Section 
3  explores  further  development  of  the  LOADMAN  system  and  details 
the  development  stages  and  discusses  the  feasibility  of  the 
various  features.  The  prototype  design  and  implementation 
including  the  hardware/software  selection,  problem  solving 
strategies,  knowledge  representation,  and  programming  methodology 
are  detailed  in  Section  4.  Section  5  discusses  the  conclusions 
and  recommendations. 


* 


SECTION  2 

DOMAIN  ANALYSIS  AND  FINDINGS 


Power  generation  and  distribution  systems  are  an  important  part 
of  the  equipment  that  an  Army  unit  needs  in  order  to  successfully 
complete  its  mission.  Power  requirements  and  importance  of  the 
different  loads  vary  depending  on  the  function  of  the  unit  - 
reconnaissance  missions,  field  hospitals,  etc.  Also,  certain 
other  factors  like  the  weather,  location  of  camp,  and  the  terrain 
could  alter  the  power  generation  and  distribution  inventory 
and/or  power  requirements. 

Apart  from  these  specific  optimization  difficulties,  the  problem 
is  complicated  by  the  fact  that  there  are  no  established 
practices  or  procedures  for  power  generation  and  distribution 
planning.  Most  equipment  (loads)  is  designed  to  be  operated 
directly  from  a  dedicated  generator,  and  so  distribution  boxes 
that  distribute  power  from  larger  generators  to  a  number  of  small 
loads  do  not  exist  or  are  not  widely  available  as  standard 
equipment.  Also,  it  is  impractical  to  transport  and  maintain 
large  numbers  of  smaller  generators.  Current  practice  indicates 
that  ad  hoc  switch  boxes  and  distribution  equipment  are  developed 
and  often  used  without  proper  regard  for  safety  and/or  technical 
soundness . 

The  domain  characteristics  and  its  suitability  for  an  expert 
system  solution  are  discussed  below.  Then,  the  various  factors 
that  could  affect  the  dependable  and  fail-resistant  operation  of 
power  generation,  distribution,  and  utilization  equipment  will  be 
addressed.  The  policy  decisions  that  should  be  made  regarding 
backup  facilities,  redundancy,  and  safety  margins  will  be 
outlined.  These  should  be  quantifiable  so  that  the  reliabilities 
of  various  power  system  configurations  can  be  calculated  and 
compared.  All  these  steps  will  make  it  possible  to  recommend 
reliability  factors  for  various  kinds  of  missions  (based  on  their 
importance) . 

Such  systematic  study  and  evaluation  of  power  distribution 
systems  is  routinely  done  in  almost  every  industry  to  ensure 
reliable  operation  and  optimization  and  should  be  of  equal  merit 
and  value  in  improving  the  effectiveness  of  the  Army  units.  A 
power  system  failure  can  render  a  unit  useless  and  adversely 
affect  the  outcome  of  the  mission. 
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2.1  ASSESSMENT  OF  THE  PROBLEM  DOMAIN  AND  ITS  SUITABILITY  FOR 
AN  EXPERT  SYSTEM 

This  assessment  Is  based  on  the  Information  gathered  from  Army 
contact  personnel,  equipment  and  configuration  data/manuals  made 
available,  and  a  JTX  trip  report. 

Several  devices  are  in  use  by  units  attempting  to  solve  power 
distribution  problems.  While  most  loads  were  designed  to  operate 
with  a  dedicated  generator,  field  personnel  usually  connect  them 
into  some  kind  of  a  distribution  system.  Few  military  standard 
distribution  boxes  are  available  and  units  that  need  others  have 
them  constructed.  These  fabricated  distribution  boxes  occupy  a 
spectrum  in  terms  of  their  usefulness  and  safety. 

All  this  raises  some  questions  about  the  suitability  of  the 
domain  (as  it  now  stands)  for  implementing  an  expert  system.  The 
success  of  expert  system  development  depends  very  much  on  the 
ability  of  the  domain  to  conform  to  the  some  basic  requirements. 
If  the  domain  is  deficient  in  some  areas,  they  should  be 
addressed  before  the  expert  system  is  actually  attempted. 
Discussed  below  are  two  requirements  which  may  not  be  satisfied 
by  our  problem  domain. 

Availability  of  experts.  A  widely  reoognized  precept  is  that  a 
problem  is  suitable  for  expert  system  implementation  when  there 
is  at  least  one  human  expert  who  is  substantially  better  at 
solving  the  problem,  does  it  routinely  and,  therefore,  has  the 
knowledge  and  experience  to  understand  the  real  problems,  to 
generate  solutions  and  to  make  (usually  correct)  decisions. 

Availability  of  teat  oases.  Knowledge  engineering  is  often 
carried  out  by  watching  the  experts  actually  solve  problems. 
Experts  tend  to  take  details  for  granted  and  omit  them  while 
describing  the  solution  process.  The  use  of  test  cases  and  the 
observation  of  the  experts  more  accurately  brings  out  the 
solution  process  and  the  knowledge  used.  These  test  cases  should 
also  be  used  for  testing  the  system  as  it  is  developed. 

Since  the  current  domain  does  not  have  such  experts  (as  gathered 
from  Army  comments  and  reports)  nor  the  requisite  test  cases,  the 
next  best  thing  is  to  form  a  body  of  knowledge  that  is  derived 
from  the  theory  of  power  generation  and  distribution  systems. 
Also,  the  lack  of  methodical  load  shedding  and  scheduling 
procedures  calls  for  establishing  some  standard  practices  which 
could  then  be  followed  and  monitored  to  ensure  the  safe  and 
reliable  operation  of  power  distribution  systems.  Only  after  the 
equipment  and  the  procedures  have  been  defined  can  an  expert 
system  be  built  to  perform  the  various  configuration  and  load 
balancing  tasks  effectively.  (To  be  precise,  such  a  system  would 
be  labeled  a  "knowledge  based"  system  rather  than  an  "expert" 
system . ) 
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2.2  FACTORS  AFFECTING  RELIABILITY 


2.2.1  Equipment  Specification  and  Design 

Power  generation  equipment.  Power  generation  equipment  used  by 
the  Army  falls  mainly  into  two  categories  -  diesel  and  gasoline. 
They  are  designed  for  various  power  levels  with  facilities  for 
varying  the  output  voltage.  The  maintenance  requirements  of  these 
generators  vary  and  there  are  other  advantages  and  disadvantages 
to  both  types.  A  study  should  be  made  of  the  various  factors,  and 
guidelines  should  be  established  for  the  appropriate  use  of  each. 
Various  considerations  are  briefly  discussed  below. 

The  end-user  confidence  in  1.5  to  10  kW  gasoline  generators  is 
low.  They  are,  in  practice,  difficult  and  time-consuming  to 
maintain.  Wherever  they  have  to  be  used,  personnel  provide  for 
two  sets  to  ensure  that  if  one  set  became  Not  Mission  Capable 
(NMC)  ,  the  other  one  could  be  used  in  its  place.  The  cost 
effectiveness  of  this  approach  should  be  examined  and  the 
substitution  of  these  with  diesel  generator  sets  should  be 
considered.  Diesel-type  generators,  mounted  on  trailers  with 
switch  boxes,  were  the  ones  most  popular  with  field  personnel 
whose  opinion  is  that  these  are  easier  to  operate  and  maintain. 
However,  the  noise  generated  by  the  diesel  generators  is  greater 
and  provision  of  quieter  designs  may  be  considered. 

Some  smaller  (3  kW)  generators  do  not  have  "breakerless"  ignition 
kits  installed,  and  starting  the  generators  poses  a  problem  due 
to  moisture  in  the  ignition  system. 

Power  distribution  equipment.  Loads  need  to  be  switched  between 
power  sources  for  various  reasons  such  as  maintenance,  breakdown 
of  generators,  etc.  In  such  cases,  a  fast,  safe  and  efficient 
change-over  is  necessary.  This  is  especially  important  where  the 
loads  cannot  tolerate  even  a  temporary  power  interruption.  Switch 
boxes  and  generation  equipment  must  be  designed  to  meet  these 
requirements  so  that  the  frequent  loss  of  critical  services 
(which  might  take  a  few  hours  to  be  reestablished)  is  avoided. 
Even  automatic  power  backup  facilities  may  be  appropriate  for. 
certain  critical  services  and  the  provision  of  such  facilities 
must  be  seriously  considered.  This  is  discussed  in  detail  in  the 
next  sub-section. 

A  new,  easy-to-understand  method  should  be  devised  for  initial 
connection  of  the  power  cable  to  the  generator,  currently,  the 
aorrect  method  of  connecting  these  cables  is  confusing.  Numerous 
pieces  of  equipment  have  been  damaged  or  destroyed  due  to 
improper  connections.  Built-in  safeguards  that  try  to  prevent 
misuse  and  improper  operation  of  equipment  should  also  be 
considered.  Matching  sockets  and  plugs  may  be  designed  into  the 
equipment  and  connecting  cables  to  ensure  proper  connections. 
Such  technology  exists  in  the  power  industry. 
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In  this  context  the  DISE  system,  which  is  an  attempt  by  the  Army 
to  design  a  standardized  distribution  system,  will  be  discussed. 
It  consists  of  the  Feeder  System,  Distribution  System,  and  the 
Lighting  and  Receptacles  System.  From  the  information  obtained, 
the  system  appears  to  be  incomplete  in  some  respects.  For 
example,  all  single-phase  outlets  are  rated  at  20A,  yet  a  number 
of  single-phase  loads  which  draw  more  than  20A  have  been 
identified. 


2.2.2  Equipment  Configuration 

The  reliability  of  a  power  system  may  be  improved  by  increasing 
the  number  of  independent  power  sources.  The  more  generators  that 
are  available,  the  lesser  the  chance  of  all  of  them  failing  at 
the  same  time.  High-powered  and/or  sensitive  equipment  will 
benefit  from  their  own  power  source  which  will  eliminate  any 
power  fluctuations  due  to  start  up  or  operation  of  other 
equipment.  The  nature  of  such  equipment  will  sometimes  dictate  a 
location  close  to  the  generator.  For  example,  X-ray  equipment 
works  better  when  it  is  located  close  to  the  power  source  so  that 
it  can  obtain  sufficient  voltage  with  minimum  fluctuations. 

Also,  the  characteristics  of  the  power  network  also  affect  the 
reliability.  For  example,  if  the  loads  were  all  strung  together 
in  tandem,  there  would  be  more  failures  than  if  they  were  all 
connected  directly  to  the  distribution  box  forming  a  star 
network.  This  is  because  the  failure  of  a  cable  would  result  in 
the  failure  of  just  one  of  the  loads  in  the  case  of  the  star 
network. 

A  related  development  is  the  work  that  has  been  done  in  the  area 
of  information/data  distribution  networks.  Various  configurations 
like  the  STAR,  RING,  BUS,  etc.,  have  been  investigated  for  the 
inherent  reliability  and  tolerance  in  the  event  of  failures.  Such 
information  could  be  used  modulated  by  other  constraints  for  a 
safe,  functional  ana  effective  power  distribution  system. 


2.2.3  Backup  Equipment 

Alternate  power  sources  are  mandatory  in  most  industries,  so  as 
to  bring  the  regular  sources  down  for  maintenance  checks.  These 
alternate  sources  would  also  be  available  as  backups  in  case  of  a 
failure.  They  are  usually  of  lower  capacity  (for  providing  just 
the  minimum  services  necessary) .  Related  issues  are  discussed 
below. 

When  an  alternate  power  supply  ought  to  be  provided  may  depend  on 
one  or  more  of  the  duration  of  the  mission,  type  of  generator, 
climatic  conditions,  type  of  load(s) ,  etc.  For  a  short  mission 
and  a  reliable  generator,  an  alternate  may  not  be  warranted.  On 
the  other  hand,  a  long  mission  under  severe  weather  conditions 
may  require  100%  redundancy.  The  rales  and  the  exceptions  should 
be  clearly  stated  so  that  they  can  be  incorporated  in  the  expert 
system  to  allow  it  to  plan  for  alternate  sources.  Mean-time- 
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betwean-failure  data  and  mission  criticality  estimates  could 
support  this  decision  making  process. 

How  much  power  ought  to  bo  provided  would  depend  on  the  demands 
of  loads  which  are  absolutely  essential  to  the  success  of  the 
mission.  Such  loads  should  be  specified  so  that  the  amount  of 
alternate  power  necessary  may  be  calculated.  For  example,  most 
signal  units  need  power  24  hours  a  day.  The  expert  system  can  use 
such  information  to  make  the  necessary  calculations  and  provide 
for  the  alternate  sources  while  preparing  the  inventory 
requirements . 

How  quickly  should  the  change-over  be  accomplished  clearly 
depends  on  the  ability  of  the  load  to  become  functional  once  the 
power  is  interrupted.  Full  automatic  backup  may  be  necessary  for 
critical  and  not-easily-reestablished  equipment.  For  example, 
some  communications  equipment  could  be  off-the-air  anywhere  from 
1  to  24  hours  once  the  power  is  interrupted  for  any  reason  and  a 
break  in  communication  occurs.  The  quality  of  backup  facilities 
that  should  be  made  available  for  various  categories  of  loads 
must  be  defined.  The  expert  system  can  use  this  information  to 
plan  for  the  necessary  backup  equipment. 


2.2.4  Use  of  Equipment 

Policies  end  procedures  need  to  be  established  for  the  proper  use 
of  power  systems  equipment.  Personnel  should  be  specially  trained 
to  work  with  generators,  switch  boxes,  distribution  boxes,  and 
the  various  loads.  This  will  prevent  accidental  misuse  of 
equipment.  For  example,  in  one  of  the  JTX's,  a  gasoline  generator 
was  mistakenly  filled  up  with  diesel  fuel. 

Guidelines  for  the  proper  loading  of  the  generators  should  be 
established  and  then  the  expert  system  could  monitor  the  load  and 
issue  a  warning  when  the  load  is  too  high  or  too  low.  This  is 
important  because  improper  loading  of  the  generator  can  cause 
"wet  stacking"  (which  refers  to  the  presence  of  unburnt  fuel  in 
the  exhaust  and  the  cylinders}  .  This  was  found  to  be  a  common 
occurrence  at  most  sites.  It  affects  the  efficiency  and 
reliability  of  the  generator. 

Personnel  should  be  trained  on  electrical  safety  procedures. 
Improper  or  insufficient  grounding  of  generators  was  found  to  be 
a  common  problem.  For  example,  cable  connections  to  light  sets 
were  not  covered  in  one  of  the  missions  and  this  would  have  posed 
a  serious  hazard  if  it  had  rained. 

A  list  of  non-military  equipment  that  may  be  used  should  be 
established.  Currently,  household  extension  cables  and  appliances 
are  widely  used  and  may  be  loading  the  various  outlets  beyond 
their  rated  capacities. 
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Power  systems  reliability  also  depends  on  the  proper  maintenance 
of  the  generators.  Procedures  and  policies  need  to  be  established 
for  the  proper  maintenance  and  checks  on  equipment.  The 
availability  of  tools,  parts,  and  trained  personnel  to  repair 
generator  equipment  is  important.  Currently,  proper  maintenance 
is  not  performed  at  most  sites  due  to  various  reasons  such  as 
nonavailability  of  switch  boxes  that  will  ensure  uninterruptible 
supply  of  power  and/or  backup  generators.  In  fact,  in  one  case  a 
generator  became  NMC  at  the  beginning  of  the  mission  due  to 
leaking  oil  seals  and  could  not  be  repaired  due  to  lack  of  repair 
parts. 

The  expert  system  can  be  designed  to  keep  track  of  all 
maintenance  related  information  and  alert  the  user  when  checks 
and  service  becomes  due.  Also,  the  inventory  planning  part  of  the 
system  could  recommend  the  repair  parts  that  would  be  needed  for 
a  particular  set  of  generation  and  distribution  equipment.  But 
first,  the  guidelines  must  be  compiled  and  made  available  to  the 
expert  system  designer. 


2.2.6  Equipment  Interaction 

Operation  of  two  heavy  loads  simultaneously  or  the  starting  of 
loads  that  produce  power  surges  while  another  heavy  load  is 
operating  can  produce  undesirable  results.  Currently,  personnel 
try  to  avoid  these  situations  from  experience.  Most  units  are 
vulnerable  to  such  load  combinations  but  they  are  not  very  well 
documented.  The  power  surge  that  is  created  by  each  piece  of 
equipment  and  information  about  loads  that  should  not  be  (need 
not  be)  operated  simultaneously  should  be  documented. 

If  these  operational  requirements  are  established,  then  they  can 
be  incorporated  in  the  expert  system  which  would  then  be  able  to 
monitor  and  regulate  the  operation  of  various  loads. 
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SECTION  3 


LOADMAN  -  A  FEASIBILITY  STUDY  CONCEPTUAL  SYSTEM  DESIGN 


A  portion  of  the  Phase  I  efforts  was  devoted  to  establishing  the 
general  philosophy,  approach,  and  feasibility  of  the  LOADMAN 
expert  system.  The  project  team's  emphasis  was  on  stretching  the 
mind,  evolving  ideas,  and  drawing  up  a  development  and 
implementation  plan  for  Phase  II.  Thus,  there  was  an  exploration 
of  ideas  and  problem  solving  strategies  which  are  described  in 
detail  in  this  section.  This  section  will  describe  our  vision  for 
further  development  of  the  project  and  the  expected  benefits  of 
an  operational  "LOADMAN"  expert  system  were  it  to  be  fully 
implemented.  The  purpose  is  to  suggest  various  problems  that 
could  be  solved  by  the  computer  system  and  elicit  feedback  as  to 
the  usefulness/ importance  of  the  various  features,  one  of  the 
advantages  of  the  object-oriented  representation  used  herein  is 
that  once  the  domain  has  been  represented  in  the  knowledge  base, 
incremental  development  of  various  specialised  applications  is 
easier. 


3.1  LOADMAN  -  DEVELOPMENT  STAGES  AND  EXPANSION  POTENTIAL 

LOADMAN  is  a  constraint  management  and  planning  system  that  will 
be  capable  of  solving  power  distribution  problems  in  battlefield 
settings  using  knowledge-based  techniques.  Although  limitations 
exist  (as  described  in  the  previous  section)  ir.  the  present 
condition  that  require  "first  time  engineering"  efforts  not 
directly  related  to  expert  system  design,  LOADMAN  can  serve  as  an 
infrastructure  or  supporting  environment  to  foster  resolution  of 
these  issues.  Further,  the  LOADMAN  conceptual  design  presented 
here  presumes  successful  resolution  of  the  open  engineering  and 
procedural  questions  and  then  provides  "placekeepers"  fov  the 
various  knowledge  elements  expected  to  be  derived  from  the  first¬ 
time  engineering  effort. 

Current  battlefield  environments  have  limited  sensor  capability 
and  no  remote  control  capability.  However,  future  enhancements  to 
current  equipment,  such  as  frequency-modulated  power  lines  for 
remote  control  and  the  addition  of  sensors  for  monitoring  of 
power  equipment,  are  possible  which  would  greatly  enhance  the 
capabilities  of  the  system.  In  order  not  to  prematurely  limit  the 
project  capabilities  as  well  as  be  sympathetic  to  current 
operating  conditions,  the  project  should  be  developed  in  stages. 
The  first  stage  will  work  with  no  sensors  and  with  manual 
input/ control .  At  the  end  of  this  stage,  the  system  will  be  an 
off-line  advisory  system  not  assuming  any  direct  control  of  the 
equipment.  It  should  then  be  capable  of  providing  logistics 
planning  advice  (how  many  generators,  distribution  boxes,  and 
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cable)  and  assisting  In  the  layout  and  the  manual  operation  of 
the  campaite  power  aystem.  The  aecond  atage  will  add  aenaora  and 
control  capabilitiea .  At  the  end  of  thia  atage,  a  totally 
autonomous  aystem  will  be  built  that  ia  capable  of  solving  most 
power  distribution  problems  without  any  help  from  the  user. 
LOADMAN  would  then  provide  generator  health  monitoring,  power 
distribution  monitoring  and  control,  and  casualty 
reconfiguration.  In  this  fashion,  the  expert  system  is  developed 
initially  as  an  advisory  system  to  help  standardize  the  domain 
and  play  a  useful  logistics  role  while  setting  the  stage  and 
gathering  knowledge  for  the  autonomous  system. 

Since  all  mission  details  and  equipment  data  is  stored  in  the 
aystem,  the  aystem  can  be  extended  to  perform  a  variety  of  other 
taska  by  adding  the  appropriate  knowledge  incrementally  (as 
needed) .  Thus,  the  system  can  help  in  ordering  the  inventory, 
planning  the  layout,  monitoring  the  distribution  system,  and 
reconfiguration  and  control  in  case  of  any  failures  or 
casualties.  There  are  other  uses  not  connected  with  the  actual 
mission,  such  as  training  personnel  to  perform  the  various  tasks 
when  the  system  is  not  available.  The  aystem  could  also  be 
enhanced  and  extended  to  keep  track  of  maintenance  and  repair 
information  and  an  inventory  of  spare  parts.  This  is  especially 
important  in  the  case  of  longer  missions  when  equipment  will  have 
to  be  pulled  off  for  maintenance  to  ensure  reliable  operation. 
Explanation  facilities  and  hypothetical  reasoning  should  also  be 
introduced  so  that  the  user  nan  query  the  system  as  to  reasons 
for  the  various  decisions  and  to  ask  "What  if?"  questions. 

LOADMAN  should  have  a  "curator"  facility  that  allows  the  system 
"custodian"  to  access  and  modify  various  parts  of  the  expert 
system.  The  curator  facility  will  be  extended  to  facilitate 
creating  and  editing  of  rules,  generation  of  reports  (e.g.,  a 
listing  of  standard  Army  power  sources) ,  and  examining  and 
modifying  knowledge  bases. 

The  system  can  eventually  be  used  for  logistics  support 
(procuring,  maintaining,  and  transporting  equipment  to  take  for  a 
specific  mission),  monitoring  of  power  generation  and 
distribution  equipment,  prediction  of  malfunctions,  and 
reconfiguration  of  equipment.  For  example,  the  system  may  detect 
that  it  is  about  to  lose  a  diesel  generator  or  about  to  shut  one 
down  due  to  fuel  shortage.  It  is  here  that  any  advice  on  system 
reconfiguration  will  be  valuable.  The  sequence  of  events  begins 
with  event  detection.  This  is  usually  detection  of  a  measurement 
that  violates  a  set-point  (threshold  value) .  The  expert  system  is 
triggered  to  begin  analyzing  the  situation  and  generate 
candidates  for  replacing  the  failed  (or  soon-to-fail)  equipment. 
This  is  followed  by  the  ranking  of  such  candidates  for  best  fit. 
For  example,  a  consideration  in  the  selection  of  a  generator  is 
its  capacity  with  respect  to  the  capacity  needed.  If  the 
generator  capacity  falls  short  of  the  needed  capacity,  it  would 
mean  shedding  some  loads.  On  the  other  hand,  if  the  generator 
capacity  is  much  higher  than  the  needed  capacity,  there  is  the 
threat  of  "wet  stacking."  This  refers  to  the  collection  of 
unburnt  fuel  in  the  exhaust  when  the  generator  is  operated 
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continuously  at  loads  considerably  less  than  full  load.  The 
reliability  and  efficiency  of  the  generator  is  adversely  affected 
in  these  circumstances. 

Load  shedding  based  on  priorities  needs  to  be  carried  out  when  a 
generator  fails  and  a  replacement  with  similar  capacity  cannot  be 
found.  To  avoid  much  reconfiguration  and/or  load  shedding,  diesel 
generator  health  monitoring  may  be  performed  on  an  on-going  basis 
so  that  the  generator  may  be  brought  down  for  repairs/maintenance 
during  periods  of  reduced  demand.  Health  monitoring  of  generators 
involves  testing  for  overheating,  overloading,  and  failures. 
Dynamic  load  balancing  based  on  operating  conditions  such  as 
weather,  enemy  threats,  casualties,  etc.,  is  yet  another  role 
that  can  be  played  by  the  expert  system. 


3.2  STAGE  I  OBJECTIVES 

Based  on  the  needs  outlined  in  Section  2.1,  the  initial  object  of 
Stage  I  should  be  to  establish  the  domain  knowledge.  Therefore, 
Stage  I  should  be  begun  bv  concentrating  on  specifying 
equipment,  establishing  policies  and  procedures  for  backup 
equipment,  and  establishing  priorities  for  the  various  loads. 
Then  the  system  can  be  built  to  plan  inventory  requirements, 
configure  the  equipment,  perform  load  shedding  when  necessary, 
and  perform  duty  cycle  scheduling  for  heavy  periodic  loads.  All 
these  applications  should  be  implemented  with  an  emphasis  on 
maximizing  efficiency  and  reduaing  the  logistics  burden.  Graceful 
degradation  in  all  of  these  areas  is  necessary  whan  the  system  is 
working  under  subopt imal  conditions  (i.a.,  when  an  optimal 
solution  cannot  be  formulated  and  some  compromises  have  to  be 
made) .  Brief  descriptions  in  the  following  paragraphs  describe 
what  is  planned  in  the  specified  areas. 


3.2.1  Load  aagsltlffatlgn  .Schema 

To  support  computerization,  all  loads  should  be  classified  into 
different  priority  levels.  We  recommend  three  levels  of  priority: 
vital,  discretionary,  and  convenience.  Also,  the  backup 
requirement  must  be  specified  on  a  load-by-load  basis.  Generally, 
the  vital  loads  may  require  100%  backup  while  the  convenience 
loads  may  not  require  any  backup  at  all.  The  discretionary  loads 
may  suggest  varying  levels  of  backup.  The  priority  and  backup 
information  should  be  stored  in  the  knowledge  base  along  with  the 
respective  loads. 

To  illustrate,  we  have  classified  certain  example  loads  into 
three  levels: 

1 

Emergency  lights 
Communications  equipment 
Command  posts 
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Discretionary 


Operating  rooms  (duty  cycle) 

Air  strips  (duty  cycle) 

Mess  halls 
Recharging  batteries 

ggnvjniencB 

Company  areas 
Street  lights 

Shower  and  sanitary  facilities 

Policies  and  procedures  should  then  be  implemented  in  code  or 
using  rules.  This  exercise  is  aimed  at  establishing  standards 
which  can  be  used  for  calculating  and  specifying  power  generation 
and  distribution  equipment. 

Context-sensitive  load  prioritization.  Scenarios  exist  where  the 
same  loads  can  be  classified  into  different  priority  levels 
depending  on  the  context. 

Thus,  priority  of  various  loads  may  be  a  function  of  mission  (or 
sub-mission).  For  example,  the  importance  of  certain  loads 
depends  on  the  nature  of  the  mission  -  offensive,  support, 
surveillance,  etc.  Another  consideration  is  the  interaction  with 
other  army  units.  For  example,  the  medical  facilities  may  be 
vital  when  a  unit  is  playing  a  supporting  role  to  units  near  the 
FEBA  (Forward  Edge  of  Battle  Area)  and  discretionary  when  the 
unit  is  stand-alone.  Load  priority  may  also  vary  depending  on  the 
usage  at  that  particular  time.  Communications  equipment  may 
require  higher  priority  while  transmitting  important  messages 
than  when  in  receiving  mode. 

The  extent  to  which  such  context-sensitive  prioritization  should 
be  implemented  is  an  issue  to  be  further  explored.  Some  of  these 
priority  levels  are  subjective  and  judgmental  and  soma  type  of 
user  override  may  be  incorporated  so  that  the  user  can  change 
priorities  if  necessary.  Due  to  this  complexity  some  work  in  this 
area  may  be  carried  over  to  Stage  II. 


3.2.2  Definition  and  Representation  of.  Constraints  and 

BflBandflDfllflft 

Constraints  are  limits  or  restrictions  that  are  placed  on  the 
value (s)  of  equipment  or  a  group  of  equipment.  Dependencies  are 
relationships  that  describe  how  certain  equipment  value (s)  are 
dependant  on  contextual  information  like  the  ambient  temperature. 
Dependencies  may  also  describe  how  certain  pieces  of  equipment 
affect  others. 

Example  constraints  are  a)  maximum  power  supplied  by  a  source,  b) 
maximum  inventory  that  can  be  carried  by  a  unit,  c)  maximum 
distance  that  can  be  covered  by  a  cable,  etc.  Constraints  should 
be  divided  into  ’’absolute  constraints"  and  "situational 
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constraint* . "  Absolut*  constraints  do  not  ohangs  with  ths 
context.  For  example,  the  maximum  distance  that  oan  be  covered  by 
a  cable  is  a  constraint  that  does  not  change  with  contextual 
information  like  the  criticality  of  the  mission.  Situational 
constraints  may  be  brought  into  effeat  depending  on  the  nature  of 
the  mission,  operational  state  of  oertain  equipment,  and 
temporal,  environmental,  safety  or  other  considerations.  They 
usually  result  from  dependencies  (as  described  in  the  previous 
paragraph) .  For  example,  the  rated  capacity  of  generators  vary 
with  the  altitude.  Situational  constraints  abound  in  a 
battlefield  setting  and  the  success  of  the  system  hinges  on  their 
specification,  representation,  and  processing.  Refer  to  Section 

4.5.2  for  information  on  the  specific  methods  of  constraint 
representation  and  processing  as  implemented  in  Phase  I. 

As  mentioned  before,  dependency  relationships  exist  between 
various  pieces  of  equipment  that  directly  affect  their 
performance*  For  example,  at  any  one  time  a  particular  source  or 
one  combination  of  sources  provides  power  to  an  active  load.  The 
performance  of  the  load  is  directly  dependent  on  the  output  of 
that  (those)  power  source(s).  Xn  LOADMAN ,  such  dependencies  are 
expressed  using  hierarchies.  Named  links  are  created  between 
objects  that  are  dependent  and  the  expert  system  can  use  these 
links  to  identify  the  dependencies. 


3.2.3  Equipment  Specification 

The  project  team  along  with  Army  personnel  should  survey  typical 
applications  for  the  average  and  peak  power  they  use  under 
various  categories:  vital,  discretionary,  and  convenience. 
Refinement  of  such  data  should  be  carried  out  and  various  methods 
of  estimation  may  be  used  for  the  three  categories.  For  example, 
the  amount  of  power  used  under  the  "vital"  and  "discretionary" 
categories  may  be  conservatively  estimated  while  the  amount  of 
"convenience"  power  is  estimated  more  strictly.  Also,  the  loads 
that  prefer  power  from  dedicated  oources  should  be  identified. 
This  may  be  because  the  loads  are  particularly  vulnerable  to 
power  fluctuations  from  other  loads.  The  power  required  by  the 
various  load  groups  should  be  analyzed  to  decide  the  power 
ratings  of  the  generators.  The  power  required  by  the  various 
loads  should  be  analyzed  to  decide  the  capacity  of  outlets  at  the 
distribution  boxes.  The  generation  and  distribution  equipment 
should  be  designed  with  these  requirements  in  mind  providing  for 
minor  variations  as  necessary. 


3.2.4  Inventory  Planning  Heuristics 

Proper  power  distribution  system  management  is  possible  only  when 
the  correct  equipment  is  available  at  the  site.  This  involves 
calculating  the  number  and  size  of  power  sources,  distribution 
equipment,  and  cables  that  would  be  necessary  to  support  the 
mission. 
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Source  heuristics.  Various  heuristics  nay  oona  into  play  at  this 
stags  to  decide  whether  and  how  to  group  tha  various  loads.  Those 
houristios  will  be  incorporated  as  rules  in  the  expert  system  and 
will  be  based  on  the  policies  and  procedures  to  be  established 
(see  Section  3.2.1).  Grouping  may  be  necessary  for  various 
reasons: 

1.  Reduce  the  interaction  between  loads.  For  example,  in  one 
case  the  dentist's  equipment  imposed  a  greater  load  on  the 
power  source.  This  would  cause  the  X-ray  equipment  to 
malfunction.  There  are  three  ways  in  which  this  situation 
can  be  tackled,  one  way  is  to  ensure  that  both  loads  are 
not  operated  simultaneously.  If  this  is  not 
desirable/possible,  we  may  consider  planning  for  a  power 
source  that  could  support  both  loads  without  the 
interference  (this  may  be  overkill  most  of  the  time) ,  or 
the  loads  could  be  powered  by  different  sources. 

2.  Different  backup  requirements.  For  example,  the  oritical 
loads  of  a  camp  like  communication  facilities  would 
require  a  higher  safety  margin  and  hsnae  a  better  backup 
facility.  But  other  loads  like  the  mess,  company  areas, 
etc. ,  will  not  require  tha  same  level  of  backup. 

3.  Too  much  load  for  one  power  source. 

Next,  we  suggest  the  calculation  of  "maximum  simultaneous  power 
required"  in  order  to  estimate  tha  power  required  of  each  power 
source.  This  refers  to  the  maximum  power  that  would  be  required 
for  eaah  group  at  any  particular  time.  Mainly,  it  takes  into 
account  the  fact  that  some  loads  can  not/will  not  be  operated 
simultaneously.  So  it  would  be  wasteful  to  provide  for  the  sum  of 
those  (power)  requirements.  The  calculation  is  done  in  two  steps. 
Step  1  involves  the  calculation  of  power  required  by  these 
"related  loads."  The  allowable  combination  of  states  for  each  set 
of  related  loads  are  examined  and  the  maximum  power  that  would  be 
required  by  each  set  is  calculated.  All  these  power  requirements 
are  summed  to  give  the  power  requirements  of  related  loads,  step 
2  involves  the  addition  of  power  requirements  of  independent 
loads  (loads  which  are  operable  whatever  the  state  of  other 
loads).  This  measure  ("maximum  simultaneous  power  required")  is 
used  to  calculate  inventory  requirements  in  terms  of  generators 
(actual  and  backup) . 

Layout  Heuristics.  After  the  power  sources  requirements  have 
been  calculated,  the  system  will  have  to  position  these  sources 
in  the  layout.  After  this,  the  connections  are  planned  between 
the  power  sources  and  the  loads.  Once  again  heuristics  in  the 
form  of  rules  will  be  used  for  this  planning.  Alternatively,  the 
user  could  be  requested  to  place  the  power  sources  and/or  specify 
the  connections. 

Inventory/Supply  Compilation.  After  the  layout  has  been 
established,  the  system  will  be  able  to  compile  the  inventory 
requirements  in  terms  of  generators,  distribution  boxes,  switch 
boxes,  cables,  and  loads. 
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Load  shedding  becomes  necessary  whenever  more  power  la  required 
by  the  varioua  loada  than  ia  available  at  that  time.  Thia  may  be 
due  to  the  failure  of  some  power  generation  or  diatribution 
equipment,  planned  ahutdown  of  sources,  inoreaae  in  the  number  of 
loada,  or  a  combination  of  the  above  factors.  The  system  must 
prioritize  the  varioua  loads  and  out  out  all  the  loada  that  are 
not  abaolutely  necessary.  Examples  of  such  loads  might  be  mesa, 
company  areas,  and  street  lights. 

The  main  goal  in  thia  situation  ia  the  maintenance  of  critical 
loads.  Example  of  such  leads  are  communication  equipment,  command 
posts,  security  points,  medical  facilities,  landing  zones,  etc.  A 
load  shedding  situation  rvpieally  starts  with  a  reduction  in 
source  capacity  or  an  increase  in  load  requirements. 

Two  methods  of  dealing  with  such  a  situation  have  been 
identified.  One  of  them  is  a  simple  desoheduling  of  already 
scheduled  low  priority  loads  to  the  point  that  the  load 
requirements  match  the  power  available.  This  may  not  be  always 
successful  (as  determined  by  some  user-defined  optimization 
testa) .  The  second  approaah  ia  to  completely  reschedule  the  loads 
based  on  priority.  In  Stage  I,  such  advice  will  be  offered  to  the 
user  who  will  be  responsible  for  switching  the  varioua  loads  as 
specified. 

Upon  partial  power  loss  or  knowledge  about  imminent  power  loss, 
the  order  in  which  the  loads  are  brought  down,  and  the  degree  to 
which  they  are  brought  down,  can  be  crucial.  With  emergency  power 
restoration  the  order  in  which  the  loads  are  brought  up,  degree 
to  whiah  they  are  brought  up  is  also  important  (for  example,  the 
emergency  generator  may  be  overloaded  by  switching  on  all  loads 
at  ''nee) .  However,  these  issues  will  not  be  addressed  in  Stage  I 
which  will  be  mainly  geared  towards  the  scheduling  problem 
itself.  Here  "scheduling"  is  the  process  by  whiah  loads  are 
selected  to  be  turned  on. 


An  example  of  this  ia  the  use  of  "turbine-gearbox  combination." 
This  piece  of  equipment  is  built  to  supply  many  loads  with 
control  over  the  power  supplied  to  each  load.  Gears  are  used  to 
vary  the  power  that  can  be  supplied  to  each  load.  It  is  thus 
possible  to  vary  the  power  drawn  by  certain  loada  to  accommodate 
other  loads.  This  kind  of  power  distribution  is  found  in  field 
hospitals  and  can  be  used  to  perform  load  balancing  based  on 
various  factors.  To  perform  the  various  calculations,  it  is 
necessary  to  convert  the  electrical  loads  to  mechanical  loads  and 
then  the  gear  ratios  to  support  such  a  load. 
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The  purpose  of  duty  cycle  scheduling  is  to  minimize  the  overall 
load  by  mashing  individual  load  requirements  to  achieve  uniform 
loading.  This  would  be  a  necessity  under  lower  power  availability 
conditions  when  it  would  be  desirable  to  spread  the  load  over 
time,  and  during  fuel  rationing  oonditions  whan  it  is  neoessary 
to  operate  all  sources  at  maximum  efficiency  for  minimum 
duration.  It  could  also  be  used  to  reduce  the  logistics  burden  of 
carrying  large  power  sources  when  smaller  sources  would  be 
sufficient  with  proper  load  operation  planning.  Also,  generators 
work  best  when  they  are  working  close  to  maximum  load.  Thus, 
planning  for  a  uniform  load  close  to  the  rated  capacity  of  the 
generator(s)  is  a  good  idea.  The  duty  cycle  scheduling  rules  will 
have  to  accept  inputs  which  specify  the  constraints  (optimization 
criteria,  max  load,  max  time  slot,  loads  to  be  scheduled,  etc.) . 
In  Stage  X,  the  duty  cycle  rules  will  advise  the  user  against 
using  combinations  of  loads  that  would  make  undesirable  demands 
on  the  power  sources. 


3.3  STAGE  II  OBJECTIVES 

Stage  II  would  involve  the  development  and  implementation  of  an 
on-line  system.  This  system  will  include  expanded  and  enhanced 
knowledge  to  accommodate s 

-  Different  kinds  of  missions 

-  Automated  interface  to  the  Power  Distribution  System 

-  Maintenance  planning 

-  Training  plan 

Various  scenarios  and  desirable  system  actions  are  described 
below  to  motivate  identification  of  needs  and  finalizing  the 
scope  of  the  project. 

a)  Camp  setting;  all  loads  operational.  Diesel  generator 
fails  dropping  available  power  to  60%  of  that  required, 
other  power  sources  may  or  may  not  be  available.  Situation 
requires  addition  of  other  sources  and/or 
reduction/reconfiguration  of  loads,  simplost  situation 
that  must  be  handled. 

b)  Changing  load  requirements  due  to  environmental 
conditions.  There  is  a  need  to  rebalance  the  loads.  Again, 
this  could  be  handled  by  reconfiguring  power  sources  or 
loads, 

c)  Periodic  loads.  Dovetailing  may  be  used  to  optimize  the 
load  with  minimum  power  requirements.  One  example  of  this 
type  of  load  would  be  the  lighting  for  airstrips. 

The  paragraphs  below  describe  applications  areas  that  are  being 
considered  at  this  time  for  implementation  in  Stage  II. 
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3.3.1  Autonomous  Monitoring  and  Control 

Autonomous,  "intelligent, "  powsr  distribution  modules  are  the 
next  step  in  improving  the  efficiency  and  execution  of  the  load 
management  system.  These  modules  can  be  designed  to  respond  to 
commands  issued  by  the  expert  system.  Closed-loop  oontrol  oan  be 
used  to  enhance  the  reliability  of  the  system.  This  is  because  in 
closed-loop  systems,  feedback  is  provided  from  the  loads  to  the 
computer  and  this  helps  the  computer  verify  that  its  commands  are 
being  carried  out.  However,  the  extra  wiring  and  sensors  that 
must  be  provided  may  make  it  prohibitively  expensive  and  so  the 

Jraotioality  of  providing  closed-loop  control  must  be 
nvestigated. 

Monitor lno  equipment  f sensors/placementl .  Monitoring  of 
generators  and  loads  is  a  must  if  the  expert  system  is  to  work 
autonomously.  The  expert  system  should  be  able  to  recognize 

?enerator  failures  so  that  it  can  bring  alternate  generators  in 
o  service.  Recognizing  load  failures  helps  the  expert  system 
schedule  other  lower  priority  loads.  The  ability  to  recognize 
load  failures  and  operation  status  is  less  important  and  so  may 
be  implemented  on  a  limited  basis.  Sensors  may  be  placed  on  the 
distribution  equipment  and  on  the  loads  for  complete  monitoring, 
on  the  other  hand,  sensors  may  be  placed  on  the  loads,  and  the 
topology  of  the  system  used  to  calculate  the  loading  at  the 
distribution.  But  the  most  cost-effective  and  perhaps  the  most 
realistic  method  is  to  place  the  sensors  on  the  distribution 
boxes.  This  will  not  help  the  system  loaate  which  particular  load 
failed,  but  would  provide  enough  information  to  calculate  power 
consumption  and  thus  the  availability  of  power  so  that  the 
scheduling  of  other  loads  may  be  planned. 

controlling  equipment.  In  addition  to  monitoring  equipment,  an 
autonomous  system  must  have  a  method  of  controlling  the 
equipment.  It  is  desirable,  both  in  terms  of  cost-effectiveness 
as  well  as  maintenance  and  logistics,  to  use  the  power  line  to 
carry  the  oontrol  signals.  One  method  (scheme)  which  has  been 
successfully  used  in  commercial  home  control  systems  works  by 
transmitting  a  high  frequency  coded  command  sequence  through  the 

?ower  lines.  This  command  sequence  is  used  to  aativate  the 
ndividual  switches  at  the  various  loads.  The  entire  system 
consists  of  one  command  module  and  many  receiver  modules.  The 
home  system  is  described  below,  but  it  is  expected  that  receiver 
modules  capable  of  higher  power  output  can  be  designed  easily. 

Command  modules.  The  command  modules  are  built  using  custom  LSI 
(Large  Saale  Integration)  ICs  (Integrated  Circuits) .  When  fully 
expanded,  the  system  can  accommodate  256  independently 
addressable  receivers.  The  function  (on,  off,  lower,  or  increase 
power)  and  address  codes  are  combined  in  the  digital  message  sent 
by  the  command  module.  The  transmitter  in  the  command  module 
generates  120-kHz  signals  that  are  used  to  modulate  the  AC  line 
with  pulse-width  modulation.  Each  message  is  transmitted  in  true 
and  inverted  format  on  successive  half  cycles  of  the  waveform.  A 
complete  message  takes  183  ms  to  complete.  Actual  attachment  to 
the  AC  line  is  accomplished  by  means  of  a  transformer  and 
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oapaoltor  oouplar.  This  isolatas  the  transmitter  from  the  power 
line  ensuring  safety  without  unduly  increasing  the  cost. 

The  command  module  can  also  be  used  to  intermittently  restore  the 
status  of  any  module  (every  so  many  minutes).  This  is  useful 
where  a  module  may  be  turned  off  by  a  transient  or  non-system- 
generated  command.  Restore  can  also  be  carried  out  at  the  command 
of  the  expert  system. 

Receiver  modules.  Each  receiver  module  incorporates  a  LSI  IC  and 
monitors  the  AC  line,  waiting  for  a  coded  message  corresponding 
to  its  address.  When  it  recognizes  a  message  addressed  to  it,  tha 
wall-receptacle  module  energizes  a  relay.  Modules  can  be  built  to 
use  a  triao  instead  and  have  the  capacity  to  increase  or  decrease 
power  to  the  load  in  response  to  control  commands.  Various 
modules  are  available  to  handle  loads  from  lamps  (lamp  modules 
rated  at  300W)  to  heavier,  non-resistive  appliances  (contact- 
closure-output  appliance  modules  rated  at  1700W) .  The  LOADMAN 
system  must  be  able  to  accommodate  heavier  loads  and  it  is 
expected  that  receiver  modules  capable  of  supplying  the  neaessary 
power  can  be  found,  or  existing  modules  can  be  redesigned  easily. 

Priority-encoded  receivers.  To  reduce  the  burden  on  the  expert 
system,  the  receiver  modules  could  be  prioritized  by 
incorporating  switches  on  them  that  select  the  level  of  priority. 
The  expert  system  can  then  turn  the  power  on  or  off  for  the 
various  priority  levels.  This  scheme  could  be  implemented  on  a 
load-by-load  basis  (at  higher  cost)  or  on  a  feeder-by-feeder 
basis  where  each  feeder  cable  could  supply  power  at  a  particular 
level  (and  could  be  turned  on  or  off).  The  computer  system  will 
use  these  levels  to  drop  loads  as  the  power  generation  or 
requirements  change.  Upon  shortage  of  power,  the  convenience 
loads  will  be  dropped  first  and  then  the  discretionary  loads  irff 
necessary.  Prioritization  of  the  receiver  modules  need  not  be 
rigid.  Depending  on  the  situation  the  priority  may  be  changed. 
For  example,  the  medical  facilities  may  be  moved  from  the 
discretionary  level  to  the  vital  level  if  there  are  many 
critically  ill  personnel  who  needed  immediate  attention.  This 
would  involve  just  changing  the  switch  position  on  the  receiver 
module  supplying  the  facility. 


3.3.2  Health. Monitoring  of  Power  Equipment 

Critical  to  power  systems  management  and  distribution  planning  is 
the  maintenance  of  equipment  (especially  power  generators) .  Some 
symptoms  that  may  signal  a  problem  are  the  overheating  and 
overloading  of  generators.  Some  sensors  are  already  available  on 
the  diesel  generators  and  others  can  be  added  easily.  However, 
such  sensor  information  must  be  fed  back  to  the  expert  system  and 
this  might  pose  a  cost  and  logistics  burden  in  terms  of  the  wires 
and  connections  that  would  be  necessary.  Perhaps,  the  location  of 
the  expert  systems  oomputer  close  to  tha  power  sources  could  help 
alleviate  the  problem.  Since  the  impact  of  such  a  health 
monitoring  system  could  be  considerable,  investigation  of  the 
idea  to  determine  its  practicability  is  worthwhile. 


Final  Report 


18 


August  10,  1988 


Battalion  Logistics  simulation  and  Training  has  been  identified 
as  key  areas  in  which  the  LOADMAN  expert  system  could  be  used.  To 
provide  for  this  capability,  the  system  should  operate  in 
advisory  mods.  Explanation  capabilities  and  the  ability  to  read 
scenario  information  from  diskettes  and  report  the  changes  in  the 
situation  to  the  user  should  all  be  implemented  to  achieve  this 
purpose.  "What  if"  reasoning  (a  feature  by  which  the  expert 
system  can  work  from  a  context  modified  by  the  user  to  produce 
solutions  suitable  to  the  new  context)  is  an  especially 
attractive  facility  that  could  be  very  valuable  in  training. 

Slice  the  representation  of  facts,  knowledge,  constraints,  and 
rules  in  LOADMAN  is  natural,  declarative,  and  object-oriented, 
the  development  of  the  above-mentioned  simulation  and  training 
facility  can  be  achieved  easily. 


3.3.4  Enhanced  Schematic  Displays 

The  camp  layout  has  been  identified  as  an  important  consideration 
in  the  processing  of  some  constraints.  Hence,  it  is  important  to 
display  the  campsite  in  as  much  detail  as  is  possible.  One  of  the 
methods  of  display  that  is  being  considered  is  to  provide  a 
graphic  display  of  the  location  and  icons  made  up  of  digitized 
pictures  to  represent  the  various  equipment.  The  user  can  select 
and  drag  these  icons  to  various  positions  on  the  screen  to 
specify  the  layout.  These  icons  will  also  be  used  to  display 
information  about  the  corresponding  equipment,  when  selected. 

The  icons  can  also  be  used  to  facilitate  user  input.  For  example, 
they  can  be  used  to  specify  equipment  that  has  failed  or  whose 
priority  has  changed.  Also,  the  display  system  could  provide  for 
editing  by  allowing  the  user  to  connect  and  disconnect  equipment. 
Parts  in  the  inventory  could  be  represented  using  digitized 
pictures  to  reduce  the  chances  of  an  error.  A  "screen  dump"  of 
such  a  display  to  the  printer  will  be  of  great  help  to  the 
personnel  who  make  the  actual  connections  in  the  field.  Digitized 
pictures  of  correct  (and  safe)  connections  at  the 
generators/loads  could  be  stored  inside  the  computer  and 
displayed  or  printed.  This  will  reduce  misconnections  and  damage 
to  costly  equipment. 

The  design  of  such  a  display  system  should  be  investigated. 
System  portability  considerations  are  bound  to  rule  out  some  of 
the  most  popular  high  resolution  systems.  But  a  good  compromise 
should  be  worth  the  effort  made  in  this  area. 
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SECTION  4 


LOADMAN  DEMONSTRATION  PROTOTYPE 


4.1  SYSTEM  DESIGN  CRITERIA 


4.1.1  Natan  .,.q£.  jfraJEtahlin 

The  nature  of  the  problem  to  be  addressed  by  LOADMAN  1s  one  of 
constraint  management  and  system  optimization  under  those 
constraints.  Example  constraints  are  a)  maximum  power  supplied  by 
a  source,  b)  maximum  inventory  that  can  be  carried  by  a  unit,  c) 
maximum  distance  that  can  be  covered  by  a  cable,  eta.  Constraints 
can  be  divided  into  "absolute  constraints"  and  "situational 
constraints."  Absolute  constraints  do  not  change  with  the 
context.  For  example,  the  maximum  distance  that  can  be  covered  by 
a  cable  is  a  constraint  that  does  not  change  with  contextual 
information  like  the  criticality  of  the  mission.  Situational 
constraints  may  be  brought  into  effect  depending  on  the  nature  of 
the  mission,  operational  state  of  certain  equipment,  and 
temporal,  environmental,  safety,  or  other  considerations.  For 
example,  the  rated  capaaity  of  generators  vary  with  the  altitude. 
Situational  constraints  abound  in  a  battlefield  setting  and  the 
suoaess  of  the  system  hinges  on  their  specification, 
representation,  and  processing. 

The  prototype  development  began  with  a  discussion  of  various 
power  distribution  and  load  management  scenarios  that  the  system 
would  be  expected  to  handle.  A  survey  of  technical  papers  was 
then  performed  to  consider  these  scenarios  against  research 
already  done  in  this  area.  Very  little  work  in  the  area  of 
generic  scheduling  systems  that  may  be  adapted  to  handle  specific 
problems  has  been  done.  One  reason  for  this  is  that  the 
complexity  of  the  problem  quickly  overwhelms  the  designer  forcing 
customized  solutions  rather  than  generic  ones.  Nevertheless,  the 
survey  provided  numerous  pointers  and  suggested  generic 
techniques  for  the  design  of  an  object-oriented,  generic 
constraint  representation  and  management  system. 


4.1.2  Development  Strategy 

The  LOADMAN  Demonstration  Prototype  was  developed  using  rapid 
prototyping  techniques  focused  on  helping  the  developers  assess 
the  feasibility  and  importance  of  the  features  and  functions  of 
the  expert  system.  Having  a  demonstration  prototype  serves  a 
secondary  purpose  of  improving  communication  of  the  concepts  to 
others.  The  rapid  prototyping  environment  creates  an  atmosphere 
where  the  consequence  of  failure  is  low,  thus,  enhancing 
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productivity  and  creativity.  The  development  objectives  of  the 
LOADMAN  demonstration  prototype  were,  thus,  directed  towards 
testing  particular  methods,  evaluating  the  feasibility  of  certain 
new  approaches  and  features,  and  providing  a  realistic  and 
interesting  simulation  of  the  full  prototype  for  review  by  the 
Army  personnel.  These  objectives  influence  the  rapid  prototyping 
guidelines  by  placing  more  emphasis  on  the  development  interface 
and  proof-of-concept  and  less  emphasis  on  performance  and 
completeness . 

Another  important  aspect  of  rapid  prototyping  is  intelligently 
bounding  the  scope  of  the  application.  The  LOADMAN  Demonstration 
Prototype  can  be  thought  of  as  a  scale  model  and  is,  thus,  a 
partial  implementation  of  the  system.  In  order  to  achieve  this, 
sacrifices  were  made  in  the  areas  of  completeness,  performance, 
functionality,  and  interfaces.  The  approach  used  to  bound  the 
Prototype  provides  tha  ability  to  establish  a  modular  development 
process  whereby,  once  the  core  functions  are  established,  new 
functions  can  be  themselves  rapidly  prototyped,  and  once 
operational,  added  to  the  core.  In  this  manner,  each  dimension  of 
the  full  prototype,  which  is  sacrificed  originally,  can  benefit 
from  the  usefulness  of  rapid  prototyping  as  it  is  added.  Thus, 
the  demonstration  prototype  provides  an  experimentation  test  bed 
for  developing  the  full  prototype. 

The  strategy  has  been  to  keep  the  specific  applications  in  mind 
while  trying  to  formulate  generic  techniques.  Design  stages  were 
followed  with  specific  implementation  stages  to  make  sure  that 
the  final  solution  will  be  relevant  and  useful.  Thus,  the  system 
has  been  designed  to  take  into  account  various  constraints  and 
recommend  equipment  and  their  placement  for  successful  load 
distribution.  The  role  of  the  system  will  eventually  span  a  wide 
area,  operating  under  different  modes  like  1)  recommendation  of 
layout  of  power  sources  and  distributors,  2)  generation  of 
inventory  requirements,  and  3)  dynamic  balancing  of  power  sources 
and  loads.  The  system  could  then  be  used  for  logistics  support, 
monitoring,  prediction,  reconfiguration  after  a  field  casualty, 
and  optimal  matching  of  source  and  load  requirements. 

However,  the  role  of  the  system  as  described  above  is  too  big  to 
be  handled  in  one  step,  preventing  methodical  design  of  lower 
level  subsystems.  In  order  for  the  project  to  be  immediately 
useful,  development  of  the  demonstration  prototype  was  made 
concentrating  on  areas  that  will  demonstrate  the  methodology  and 
feasibility  of  the  project  without  requiring  additional  equipment 
or  interface  to  the  power  generation  and  distribution  system. 


4.2  HARDWARE,  SOFTWARE,  AND  INTERFACE 


4.2.1  Hardware  Selection 

Since  the  logical  conclusion  of  this  project  is  to  provide  army 
units  with  this  computer  system  (so  that  dynamically  developing 
problems  at  the  site  can  be  handled)  ,  the  hardware  must  be 
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inexpensive.  Also,  versions  of  the  machine  should  be  available 
that  oould  be  carried  and  used  easily  in  the  field.  Thus,  the 
project  was  developed  on  an  AT-class  Personal  Computer  which  is 
the  least  expensive  and  portable  machine  that  can  support  a  LISP- 
based  object-oriented  delivery  environment.  A  Color  Graphics 
Adapter  "text  mode"  screen  is  used  for  displaying  the  layout  of 
the  site  because  this  offers  maximum  speed  with  minimum 

frocessing  power.  In  this  display  mode,  the  screen  is  divided 
nto  80  columns  and  25  lines  of  character  areas  and  only  the 
ASCII  characters  and  symbols  can  be  displayed  in  each  of  these 
areas.  The  exact  details  of  the  Demonstration  Prototype  hardware 
are  as  follows; 

IBM  PC/AT  or  100%  compatible  with 
MS-DOS  3.0  or  higher 
Serial  port 
Floppy  drive 

Hard  disk  (10  M  available  room) 

Color  Graphics  Adapter  and  Monitor 
5  MB  Extended  memory 
Three-button  mouse 


4.2.2  soCfcwaca  fifllflsfcifln 

For  the  purposes  of  expert  systems  development,  including  rapid 
prototyping  and  testing,  an  entire  development  environment  with 
debugging  tools  is  a  must.  Thus,  Golden  Common  LISP  286  developer 
package  and  KEYSTONE  (a  hybrid  expert  system  development  and 
delivery  environment)  were  the  software  tools  used.  Decision  on 
the  software  tools  was  baaed  on  the  knowledge  representation 
capabilities,  sophisticated  developer's  interface,  and  low  cost 
at  the  time  of  delivery.  In  addition  to  frame-based 
representation  and  rule  processing,  KEYSTONE  provides  a  versatile 
windowing  environment  which  provides  the  flexibility  for  trying 
out  different  screen  configurations  and  display  methods. 

Once  the  interface  design,  knowledge  representation,  and 
processing  have  been  finalized,  a  few  advantages  of  the 
development  environment  could  be  given  up  for  advantages  in  the 
form  of  cost,  transportability,  and  more  modest  hardware 
requirements  so  that  the  delivery  environment  is  viable. 


4.2.3  System  Interface 

The  LOADMAN  system  interface  is  an  advanced  and  functional 
interface  using  windowing  facilities  and  mouse  and  menu  based 
selection  and  input.  This  is  based  on  the  windowing  and  menu 
facilities  provided  by  KEYSTONE  (the  underlying  hybrid 
development  shell) . 

Apart  from  displaying  a  plan  of  the  campsite,  the  interface  helps 
the  user  create  knowledge  representations  for  a  particular 
mission  and  associated  equipment.  Also,  the  interface  allows  the 
user  to  control  the  inventory  of  equipment  used  by  a  mission 
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using  menu-based  instance  craation  facilities.  For  example,  the 
user  can  create  a  "TELEPHONE"  instance  using  the  Inventory  menu 
and  place  it  on  the  layout. 


4.3  KNOWLEDGE  REPRESENTATION  AND  REASONING  METHODOLOGY 


4.3.1  Object-oriented  Domain  Representation 

Object-oriented  programming  is  an  expert  systems  engineering 
technique  where  system  components  and  their  inter-dependencies 
are  represented  using  "software"  objects  and  slots  within  the 
expert  system.  Object-oriented  programming  also  makes  use  of  code 
attached  to  objects  to  provide  a  highly  modular  and  manageable 
implementation.  This  approach  is  well-suited  for  modeling  inter¬ 
relationships  between  generators,  loads,  cables,  etc. 

Definition  of  the  domain  objects  is  carried  out  through  a  user- 
friendly  interface  which  is  designed  such  that  the  system  curator 
need  not  have  any  special  knowledge  in  the  AI  field.  The 
knowledge  required  for  this  process  consists  of  characteristics 
of  the  components  and  their  relationship  with  other  components. 
Typically,  such  information  is  well  known  by  the  curator  or  is 
available  from  specialists.  This  object-oriented  approach  to 
knowledge  representation  allows  the  knowledge  base  to  be  modified 
simply  by  adding  (or  removing)  objects  and  readjusting  the 
associated  links  between  the  new  arrangement  of  constructs.  The 
advantages  of  object-oriented  programming  follow: 

Natural  wav  of  representing  knowledge.  The  system  is  modeled  to 
explicitly  represent  the  funotion  and  relationships  of  individual 
system  elements. 

Adaptability.  The  knowledge  base  is  inherently  modular  and  does 
not  rely  upon  compiled  knowledge,  i.e.,  knowledge  gathered  from 
previous  specific  scenarios  and  applications.  This  makes  it 
easier  to  use  the  same  knowledge  base  for  different  applications 
and  hence  adaptable. 

Increased  life  cycle.  The  knowledge  base  can  be  modified  and 
extended  easily  to  reflect  changes.  Also,  the  knowledge  base  can 
be  fine-tuned  by  refining  the  knowledge  incrementally. 

Verifiability.  Explicit  knowledge,  that  is  found  in  object- 
oriented  systems,  is  easier  to  verify  because  of  the  independent 
nature  of  each  "chunk"  of  knowledge. 


4.3.2  Reasoning  Mechanisms 

Rule-baBed  Reasoning.  The  reasoning  process  in  this  system 
combines  factual  domain  information  with  the  heuristics  of  the 
human  experts.  Facts  are  independent  pieces  of  information  which 
are  best  represented  declaratively.  Constraints  are  facts  that 
place  a  limitation  on  one  or  more  domain  objects.  Heuristic 
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information,  in  tha  form  of  rules,  use  facts  to  generate 
"intermediate  facts"  or  infer  conclusions  and  solutions.  They 
(the  rules)  are  processed  by  an  inference  engine. 

In  this  domain  we  envisage  two  sets  of  rules,  l)  dependency  rules 
for  generating  situational  constraints  from  situational 
(contextual)  data  using  dependency  heuristics,  and  2)  planning 
rules  for  generating  the  schedule  using  the  collection  of 
absolute  and  situational  constraints  and  factual  domain 
knowledge.  Figure  1  illustrates  this  concept  graphically.  These 
rules  may  be  further  subdivided  into  rule-classes  according  to 
their  specific  function.  This  structuring  of  rules  improves  the 
modularity  of  the  system  making  it  easier  to  design,  maintain, 
and  extend  the  system.  In  the  demonstration  prototype,  rules  are 
used  in  a  limited  manner,  mainly  to  determine  the  violation  of 
proximity  constraints. 

In  developing  the  rule-bases  one  should  recognize  that  rule 
testing  may  be  repeated  unnecessarily  if  the  rules  are  not 
carefully  programmed.  Developing  an  efficient  and  consistent  set 
of  rules  for  a  complicated  domain  can  be  expensive  and  time- 
consuming.  This  is  where  the  above  structuring  of  rules  will  help 
in  focusing  rule  processing  and  improve  the  efficiency  of  rule 
processing. 

Conventional  Programming.  Some  procedural  components  of  the 
solution  process  are  handled  using  conventional  programming  in 
the  form  of  LISP  code. 


4 . 4  SYSTEM  IMPLEMENTATION 


4.4.1  LQADMM  Knowing, Q„.Bqg9 

Since  the  LOADMAN  system  is  object-oriented,  all  entities  in  the 
problem  domain  are  represented  using  objects.  Objects  are 
logically  grouped  into  "knowledge  bases."  This  helps  the  expert 
system  and  the  user  locate  and  process  the  object  easily.  Objects 
may  be  organized  into  hierarchies  which  helps  classify  them  into 
the  various  "types."  For  example,  the  "SOURCES"  object  represents 
the  class  of  objects  that  are  power  sources,  such  as  "diesel 
generators,"  Therefore,  all  power  generator  objects  in  the  system 
would  be  below  the  SOURCES  object  (in  the  hierarchy). 
Graphically,  a  knowledge  base  is  represented  using  the  names  of 
the  various  objects  and  lines  between  the  names  to  specify  the 
hierarchical  relationships.  Several  hierarchical  relationships 
may  exist  in  one  knowledge  base  and  some  hierarchies  may  extend 
into  other  knowledge  bases.  See  Figure  2  for  an  illustration. 

The  LOADMAN  expert  system  lias  a  system  knowledge  base  called 
"LOADMAN"  that  aontains  objects  that  store  global  information 
(information  that  is  generally  applicable  within  the  domain). 
Thus,  this  knowledge  base  contains  template  objects  representing 
most  domain  objects.  These  template  objects  have  all  the  various 
slots  that  are  necessary  to  fully  describe  the  domain  object,  but 
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Figure  1.  The  Reasoning  Process 
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Figure  2.  LOADMAN  Knowledge  Base  Structure 
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with  none  of  the  •pacific  information  fillad  in.  In  other  words, 
they  are  prototypical  aoftwara  objects  that  daacriba  every  item 
that  could  ba  part  of  a  mission  (generators,  radios,  tents, 
telephones,  etc.).  Examples  of  such  objects  are  30-KW-GENERATOR, 
6 0 -KW-GENERATOR ,  120-V-RADIOS ,  etc.  The  slots,  along  with  default 
values,  will  be  inherited  by  specific  instances  when  they  are 
created  in  various  missions.  The  LOADMAN  knowledge  base  is  one  of 
the  knowledge  bases  shown  in  Figure  2. 


4.4.2  Mission  Representation  and  Handling 

The  previous  section  described  the  system  knowledge  base, 
"LOADMAN."  Other  knowledge  bases  are  created  as  missions  are 
loaded  into  the  system  or  created  afresh.  LOADMAN  has  been 
designed  to  model  missions  independently.  Each  mission  will  be 
given  a  mission  name  by  the  user  and  this  will  be  used  to  oreate 
a  knowledge  base  and  store  mission-specific  information.  The 
details  of  the  mission  oan  ba  entered  by  the  user  and  saved  for 
future  reference.  The  mission  knowledge  base  stores  different 
kinds  of  information  like  the  camp  size,  altitude,  and  the  nature 
of  the  mission  in  a  structured  manner.  It  also  stores  information 
like  the  location  of  a  particular  load,  power  requirements  of 
loads,  and  their  role  (main,  backup) . 

The  Blackboard  object.  An  object  of  central  importance  in  eaoh 
mission  knowledge  base  is  the  Blackboard.  This  stores  general 
information  that  does  not  correspond  to  any  one  object  that  is 
part  of  the  mission.  For  example,  the  number  representing  the 
number  of  instances  of  a  particular  type  of  object  and  the 
maximum  number  of  such  instances  allowed  are  specific  to  one 
particular  mission  but  not  to  a  particular  instance.  So,  slots 
named  after  the  type  objects  are  created  in  the  Blackboard  object 
and  used  to  store  the  maximum  number  and  the  current  oount  of  the 
instances . 

Other  important  slots  in  this  object  are: 

PROXIMITY-CONSTRAINT  -  This  stores  the  proximity  constraints 
that  are  specific  to  a  mission. 

CAMP-SIZE  -  This  stores  the  aamp  size  in  feet  (e.g.,  Height: 
200,  Width:  550) 

DISPLAY-GRAPH  -  The  value  of  this  slot  specifies  what  value 
to  display  on  the  "Overall  power  status"  graph.  For  example, 
if  the  value  is  SHOW-USED  then  the  graph  represents  power  that 
is  used  up  by  loads  that  are  already  scheduled  against  time. 

MISSION-START  -  The  value  of  this  slot  represents  a  reference 
number  that  indicates  the  start  time  of  the  mission.  This  is 
usually  0. 

MISSION-END  -  The  value  of  this  slot  represents  a  number  that 
indicates  the  end  time  of  the  mission.  It  is  an  integer  that 
represents  the  number  of  minutes. 
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POWER- AVAILABLE  -  This  slot  stores  tha  power  availability 
pattarn.  It  ia  a  list  of  liata  with  each  aublist  rapresanting 
a  ohanga  in  tha  amount  of  powar  available.  The  firat  item  in 
tha  aublista  is  an  intagar  which  represents  tha  time  of  the 
powar  change  relative  to  the  start  of  the  mission.  The  second 
item  in  each  subliat  represents  tha  new  power  (in  watts) . 

VIOLATIONS  -  This  slot  holds  details  of  any  violation  of 
constraints . 

WARNING-FLAG  -  Flag  that  is  set  when  constraint  warnings  are 
encountered. 


4.4.3  invintorv  RflprBaentatlcn.  and  Handling 

Each  piaoa  of  equipment  in  tha  mission  is  represented  by  an 
object  in  tha  mission  knowledge  base.  This  objaot  will  be  an 
instance  of  a  "type"  object  in  the  LOADMAN  knowledge  base  and, 
thus,  will  inherit  all  its  functional  characteristics  from  tha 
"type"  object.  Equipment  "types"  can  be  accessed  through  the 
Inventory  menu  and  instances  created  as  necessary.  Each  such 
instance  will  also  be  a  member  child  of  the  LAYOUT  object. 

The  system  automatically  generates  names  for  these  objects  by 
concatenating  a  number  (which  is  incremented  every  time  an  object 
of  a  particular  type  is  created)  to  the  "type"  object  name.  For 
example,  when  the  fifth  instance  of  115-V-RADIO  is  created,  it 
will  be  named  U5-V-RADX0-5.  When  an  instance  is  created,  the 
user  is  asked  to  place  the  object  on  the  layout.  This  location  is 
stored  on  the  object  and  used  to  position  the  object  in  the 
Layout  and  Zoom  windows. 

Example  Load  Instance.  115-V-RADIO-3  is  an  instance  of  115-V- 
RADIO  and  has  the  following  slots: 

ASSOCIATED-OBJECTS  -  This  slot  stores  objects  whose  use  is  in 
some  way  related  to  this  instance.  In  other  words,  this  slot 
represents  other  objects  in  the  mission  that  have  common 
simultaneous  constraints  with  this  object. 

CAN-CONTAIN-ITEMS  -  This  is  a  flag  which  indicates  whether  a 
particular  load  instance  can  include  other  load  instances.  For 
example,  a  TENT  (which  is  itself  a  load)  can  contain  other 
loads  like  TELEPHONES,  etc. 

INSTANCE-OF  «  This  stores  tha  name  of  the  "type"  object.  For 
example,  the  value  here  is  115-V-RADIO. 

SYMBOL  -  Stores  an  ASCII  symbol  that  is  used  to  represent  the 
object  in  the  layout.  Here,  the  symbol  value  is  'R.' 

VOLTS  -  Stores  the  voltage  required  by  this  load  (e.g.,  115) . 

LOCATION  -  Stores  the  location  of  th j  object  on  the  layout. 
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PART-NUMBER  -  Stores  the  Army  part  number  for  this  objeot. 
Here,  it  would  be  AN/TRC-110. 

POWER  -  Stores  the  power  required  by  this  load  (in  Watts)  for 
the  various  operating  states.  For  example,  "OFF:  0  RECEIVING: 
1000  TRANSMITTING:  4318"  represents  the  power  required  by  115- 
V-RADIO-3 . 

POWER-FROM  -  Slot  stores  the  source  from  which  this  load 
receives  power  (e.g.,  60-KW-GENERATOR-l) . 

PRIORITY  -  Stores  a  number  between  1  and  9  as  the  priority  of 
the  load.  Lower  numbers  denote  lower  priority. 

POWER-NEEDED  -  Stores  the  on  and  off  times  that  is  planned  for 
this  load. 

Example  Source  Instance.  60-KW-GENERATOR-l  is  an  instance  of  60- 
KW-GENERATOR  and  has  the  following  slots: 

CONSUMPTION  -  Slot  stores  the  rate  of  fuel  consumption,  in 
gallons  per  hour.  Here  the  value  is  6  gal/hr. 

FUEL-CAPACITY  -  Specifies  the  maximum  amount  of  fuel  that  can 
be  stored  in  the  generator. 

LOCATION  -  Stores  the  location  of  the  objeot  on  the  layout. 

PART-NUMBER  -  Stores  the  Army  part  number  for  this  object. 
Here,  it  would  be  PU/700. 

POWER  -  Stores  the  rated  power  output  (in  watts)  of  this 
source  (e.g.,  60000). 

POWER-TO  -  Stores  all  load  objects  that  this  source  provides 
power  to  (e.g.,  115-V-RADI0-3,  TELEPHONE-1,  etc.). 

SYMBOL  -  Stores  an  ASCII  symbol  that  is  used  to  represent  the 
object  in  the  layout.  Here,  the  symbol  value  is  'G.' 

VOLTS  -  Stores  the  voltage  at  which  this  source  provides  power 
(e.g. ,  416  V) . 

Other  slots  in  the  source  instance  object  store  methods  to 
create,  delete,  create-name,  draw,  undraw,  display,  etc.  The 
LOADMAN  system  supplies  standard  methods  to  achieve  all  this,  but 
the  user  is  free  to  modify  or  introduce  different  procedures. 


4.4.4  Layout  Representation 

Representation  and  display  of  the  campsite  is  an  important 
feature  of  the  LOADMAN  system.  This  is  because  equipment 
positioning  and  interconnection  plays  a  significant  role  in  load 
management  planning  and  inventory  planning.  The  objects  that  are 
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used  to  represent  such  information  ara  daaoribed  below.  These 
objects  are  created  for  every  mission. 

The  Layout  Object.  The  object  that  ties  together  all  domain 
instances  is  the  LAYOUT  object.  This  object  has  slots  that 
specify  various  parameters  used  for  representing  a  campsite  on 
the  display.  Also,  all  equipment  instances  (loads,  sources, 
distributors,  etc.)  which  are  part  of  the  mission  are  child 
objects  of  the  Layout  object. 

The  Layout  object  has  the  following  slots: 

LAYOUT-X-SCALE  -  This  slot  stores  the  scaling  factor  that  is 
used  when  the  campsite  is  displayed  on  the  screen.  In  other 
words,  it  is  the  number  of  feet  that  each  character  cell  on 
the  screen  represents  -  in  the  X  direction  (e.g.,  10 
feet/cell) . 

LAYOUT-Y-SCALE  -  This  is  the  scaling  factor  that  is  used  in 
the  Y  direction  (e.g.,  IS  feet/cell). 

MULTI-ITEM-SYMBOL  -  This  specifies  the  symbol  that  is  used  to 
represent  multiple  items  that  fall  in  the  same  cell  in  either 
the  Layout  or  the  Zoom  window. 

POSITIONS  -  This  stores  all  instance  objects  that  are 
currently  displayed  in  the  LAYOUT  window  and  their  screen 
positions  (relative  to  The  LAYOUT  window's  origin) . 

ZOOM-POSITIONS  -  This  stores  instance  objects  that  are 
currently  displayed  in  the  ZOOM  window  and  their  screen 
positions  (relative  to  the  ZOOM  window's  origin) . 

ZOOM-X-SCALE  -  This  slot  stores  the  scaling  factor  that  is 
used  for  the  Zoom  window,  in  the  X  direction  (e.g.,  5 
feet/cell) . 

ZOOM-Y-SCALE  -  This  slot  stores  the  scaling  factor  that  is 
used  for  the  Zoom  window,  in  the  Y  direction  (e.g.  ,  5 
feet/cell) . 

Layout-panel  object.  The  slots  in  this  object  store  window- 
specific  information  about  the  Layout  display.  The  various  slots 
in  the  object  describe  the  window's  color,  border  width,  methods 
for  window  operations  (such  as  create,  delete,  open  close,  etc.) , 
title,  region,  and  the  windows  used  as  X  and  Y  pan  bars. 

Zoom-panel  object.  The  slots  in  this  object  store  window- 
specific  information  about  the  Zoom  display.  The  various  slots  in 
the  object  describe  the  window's  color,  border  width,  methods  for 
window  operations  (such  as  create,  delete,  open  close,  etc.), 
title,  and  region.  The  CELL-LOCATION  slot  stores  the  location  of 
the  ZOOM  area  on  the  Layout  window  (in  screen  coordinates) . 
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I.S  SYSTEM  UTILIZATION 


:h«  LOADMAN  system  is  window  and  menu  based  and  is  easy  to  use 
(or  tho  most  part.  Routines  that  prompt  the  user  to  add  or  delete 
Information  to/ from  the  knowledge  bases  have  been  created.  These 
dll  insulate  the  user  from  the  software  details  through  the  use 
>f  menus  and  specific  questions  about  the  item  being  updated, 
important  system  funotions  can  be  invoked  using  the  main  menu 
rtiich  oan  be  accessed  from  the  LOADMAN  icon.  The  main  menu  can  be 
accessed  by  placing  the  mouse  cursor  on  the  LOADMAN  icon  and 
pressing  the  left  button.  A  selection  can  be  made  by  moving  the 
nouse  cursor  to  a  particular  choice  and  releasing  the  button.  The 
LOADMAN  ioon  and  main  menu  are  shown  in  Figure  3. 

As  mentioned  earlier  (Section  1.3),  development  of  the 
demonstration  prototype  was  suspended  due  to  gaps  in  domain 
knowledge  which  made  it  very  difficult  to  proceed  with  the 
completion  of  the  prototype.  The  efforts  were  redirected  into 
establishing  the  general  philosophy  and  the  methods  to  be 
followed  in  implementing  a  system  of  this  nature.  Parts  of  the 
prototype  which  were  implemented  up  to  that  point  are  described 
here  to  demonstrate  that  advanced  (knowledge  based)  oomputer 
techniques  could  be  used  to  solve  load  management  problems. 


.5.1  campsite  Displays  and  Inventory  Menu 

Two  windows  on  the  computer  display  will  be  used  to  display  the 
camp  layout  at  any  time.  One  of  these  will  display  a  major 
portion  of  the  camp  at  low  resolution  and  the  other  one  will  be 
used  to  zoom  into  a  specific  area  of  the  camp.  They  are  aalled 
the  LAYOUT  and  ZOOM  windows  respectively.  These  are  shown  in 
Figure  4.  The  campsite  layout  display  can  be  scrolled  up  and  down 
or  panned  left  to  right  to  examine  the  entire  campsite.  The 
LAYOUT  and  ZOOM  windows  have  been  designed  and  implemented  to 
help  the  user  accurately  position  the  loads  on  the  layout.  The 
LAYOUT  object  stores  the  scaling  factor  of  the  LAYOUT  window  and 
the  ZOOM  window,  as  well  as  tho  screen  positions  of  each  object 
drawn  in  the  LAYOUT  and  ZOOM  windows. 

The  Inventory  menu  (see  Figure  4)  and  the  LAYOUT  and  ZOOM  windows 
are  very  functional.  For  example,  all  symbols  on  the  LAYOUT  and 
ZOOM  windows  represent  object  instances  and  are,  mouse-sensitive. 
Information  about  these  instances  can  be  obtained  by  placing  the 
mouse  cursor  on  these  symbols  and  clicking  the  buttons.  Also, 
instances  may  be  deleted  or  their  software  object  displayed  etc. 
More  specific  information  on  all  these  can  be  found  in  Appendix 
A,  "Tutorial/Demonstration  Sheet.” 

LAYOUT  Window-  The  LAYOUT  window  is  designed  to  show  a  major 
portion  of  the  camp  with  vary  low  resolution.  It  is  also  designed 
so  that  it  can  be  used  to  pan  around  the  entire  camp.  The 
resolution  of  the  LAYOUT  window  can  be  modified  by  the  user.  The 
user  can  mouse  on  any  item  in  the  LAYOUT  window  and  bring  up, 
among  other  things,  an  explanation  of  the  item.  This  gives  some 
key  information  regarding  the  item.  Likewise,  the  user  can  also, 
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delete  the  item,  stove  it  to  a  different  location,  or  display  the 
software  object  that  describes  the  itesi. 

zoom  window.  The  ZOOM  window  is  designed  to  show  a  small  portion 
of  the  camp  at  a  higher  resolution  than  the  LAYOUT  window.  It  can 
be  moved  around  and  positioned  on  a  small  part  of  the  LAYOUT 
window  (using  the  mouse) .  This  allows  the  user  to  position  the 
equipment  with  greater  accuracy  by  first  moving  the  ZOOM  window 
to  the  general  area  and  then  indicating  the  specific  position  of 
the  equipment  in  the  ZOOM  window. 

Manus .  A  major  portion  of  the  demonstration  prototype  is  menu- 
driven.  This  makes  it  very  easy  for  the  novice  to  learn  to  use 
the  system.  Whan  the  LOADMAN  environment  is  initialized,  a 
LOADMAN  text-icon  is  created.  The  Main  Menu  can  be  accessed  from 
this  icon  (Figure  3).  This  menu  has  options  to  Create  Mission, 
Delete  Mission,  Change  the  current  mission,  and  Show  Inventory 
menu  for  the  current  mission.  In  addition  this  menu  has  a  Curator 
option  which  allows  the  user  to  modify  load  and  sources 
information,  and  constraints.  Figure  5  shows  the  curator  menu 
selections.  All  major  mission  manipulation  functions  can  be' 
accessed  through  this  menu. 

The  Inventory  menu  shows  the  current  count  and  maximums  for  eaah 
system  known  to  the  system.  The  description  of  the  items  can  be 
either  the  part  number  or  a  "pseudo-name"  describing  what  the 
item  is.  For  example,  telephones  can  be  either  "AN/TCC-73V2"  or 
"TELEPHONES."  Each  item  can  be  selected  using  the  mouse  to  bring 
up  a  menu  of  actions  that  can  be  performed  in  that  item  class. 
These  actions  are: 

ADD:  creates  a  new  item  instance,  asking  the  user  to  position 
the  item  in  the  Layout/ Zoom  windows,  checking  to  be  sure  the 
maximum  has  not  been  exceeded. 

DELETE:  Prompts  the  user  with  a  menu  of  all  known  instances  of 
the  item  type.  If  the  user  chooses  one,  it  is  deleted. 

DISPLAY:  Displays  the  selected  item's  "type  object"  in  a 
window. 

MAXIMUM:  Allows  the  user  to  enter  the  maximum  number  of  this 
item  type  allowed  in  the  camp.  If  the  number  is  less  than  the 
number  currently  positioned,  the  change  will  not  be  made. 
Using  this  feature,  the  user  can  guard  against  inadvertently 
using  more  equipment  than  is  available. 


4.5.2  Specification  and  Processing  of  Constraints 

Proximity  constraints.  Proximity  constraints  allow  the  user  to 
speaify  spatial  constraints  on  the  location  of  certain  objects 
with  respect  to  other  objects.  In  other  words,  proximity 
constraints  specify  that  particular  load  instances  or  all 
instances  of  a  particular  load  class  cannot  be  closer  or  must  be 
closer  than  a  specified  distance  from  another  instance  (or  class 
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of  instances) .  For  example,  RADIOS  must  be  closer  than  20  feet 
from  ANTENNA- 1 .  Also,  the  perimeter  of  the  camp  can  be  a 
constraint  (e.g.,  RADIO- 1  must  be  further  than  50  feet  from  the 
camp  perimeter) .  The  proximity  constraints  are  divided  into  two 
types:  load  proximity  and  perimeter  proximity.  These  enforce, 
respectively,  load  class/ instance  to  load  class/ instance  distance 
and  load  class/ instance  to  camp  perimeter  distance  conditions. 
Proximity  constraints  can  be  modified  by  using  the  "Curator" 
selection  on  the  Main  menu.  A  set  of  rules  and  associated  support 
functions  were  created  using  KEYSTONE'S  inference  mechanism  and 
the  LISP  language,  which  allows  both  pattern  matching  and  LISP 
function  calls  to  enable  the  expert  system  interpret  the 
constraints.  Some  interface  routines  have  been  written  to  allow 
the  user  to  specify  such  constraints  without  any  programming 
knowledge . 

Proximity  constraints  are  used  in  Load  Positioning  (where  the 
system  automatically  decides  where  various  loads  should  be  placed 
at  the  campsite)  and  Distribution  Networking  (where  the  system 
decides  where  the  distribution  boxes  should  be  placed  amongst  the 
different  loads  and  how  the  entire  system  should  be  connected) . 
See  Section  4.5.4  for  an  outline.  At  this  time,  each  load  item  is 
checked  against  the  list  of  constraints.  If  it  has  a  constraint 
(either  specifically  that  instance  (e.g.,  RADIO-1)  or  its  class 
(e.g.,  RADIOS),  its  distance  to  the  closest  camp  boundary  is 
computed  and  compared  to  the  constraint  (either  for  too  low  a 
distance  or  too  high  a  distance) .  If  a  violation  occurs,  the 
instance  and  the  constraint  are  stored  on  the  mission  blackboard 
for  either  perusal  or  later  processing.  A  message  is  also 
displayed  on  the  screen.  For  load  proximity  constraints,  the 
process  is  the  same,  except  the  load  must  be  compared  to  all  load 
instances  specified  in  the  other  half  of  the  constraint;  for 
example,  "RADIO-1  must  be  closer  than  10  feet  to  ANTENNA-1."  In 
this  example,  the  RADIO-1  instance  would  be  compared  to  the 
ANTENNA-1  instance,  their  distance  computed,  and  the  distance 
compared  to  the  constraint. 

Simultaneous  Constraints.  Simultaneous  constraints  are 
limitations/relationships  that  exist  between  loads  such  that 
certain  operational  states  are  not  simultaneously  attainable  or 
are  avoided  by  the  operators.  In  other  words,  these  constraints 
represent  load-state  combinations  that  the  expert  system  need  not 
provide  for  when  planning  power  sources.  For  example,  in  a  radio¬ 
antenna  combination,  the  antenna  is  not  moved  while  the  radio  is 
transmitting.  Since  both  these  functions  (transmitting  and  moving 
(tracking))  are  costly  in  terms  of  power,  the  constraint 
information  that  both  of  these  cannot  happen  simultaneously  is 
useful  for  estimating  the  amount  of  power  that  should  be  planned 
for  these  two  loads. 

In  processing  simultaneous  constraints,  the  system  calculates  the 
power  that  is  used  by  related  loads  (in  the  example:  the  radio 
and  the  antenna)  in  the  various  legal  (allowed)  operational  state 
combinations.  The  maximum  power  that  is  possible  in  any  legal 
load-state  combination  is  taken  as  the  amount  of  power  to  be 
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reserved  for  those  loads.  See  Table  4-1  for  an  example 
calculation.  Here  750W,  corresponding  to  radio  TRANSMITTING  and 
antenna  ON,  Is  the  maximum  power  that  can  be  taken  up  by  the 
RAOIO-ANTENNA  load  combination  and  so  the  expert  system  will  plan 
to  provide  750W  for  these  two  loads. 


Table  4-1 

Load-Instanoe/Operational-State  Combinations 
for  Antenna-1  and  115V-RADIO-1 


4.5.3  primary., and  Alternate , P.awgr„,  B«gulr.«BLBnfca 

The  first  step  in  estimating  the  primary  and  alternate  power 
requirements  of  a  mission  or  campsite  is  the  estimation  of 
overall  primary  power  under  all  allowable  load/atate 
combinations.  The  overall  power  required  by  a  mission/oamp 
depends  not  only  on  the  loads  that  are  part  of  a  mission,  but  the 
various  operational  states  that  the  loads  may  assume  in 
relationship  to  one  another.  Such  relationships  help  in 
estimating  the  power  requirements  closely  so  that  the  smallest 
power  generation  equipment  that  will  do  the  job  can  be 
transported  and  used.  This  is  important  in  terms  of  efficiency 
because  generators  operating  close  to  full  load  are  the  most 
efficient,  and  also  in  terms  of  logistics  where  it  is  preferable 
to  transport  a  smaller  generator  if  it  is  sufficient  to  fulfill 
the  needs. 

"Simultaneous  constraints"  are  used  to  specify  the  relationships 
described  above  and  their  specification  and  processing  in  Section 
4.5.2.  The  use  of  simultaneous  constraints  in  LOADMAN  is  menu- 
based  and  straightforward.  The  user  selects  the  load-instance/ 
operational-state  combinations  which  are  not  "simultaneously 
allowed,"  using  various  menus  presented  by  the  system.  This 
process  is  described  below. 
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Addlnq-fllaultantpug  -.CQnatr.alnta  •  It  is  assumed  hers  that  the 
"type"  object  of  the  load  Instance  describes  the  various 
operational  states  that  the  object  can  assume  and  the 
corresponding  power  levels.  If  this  is  not  the  case,  the  user 
should  use  the  "ADD  STATE"  selection  from  the  menu  which  can  be 
accessed  by  clicking  the  left  button  on  the  instance  symbol 
(e.g.,  "R"  for  11BV-RADI0-1)  in  the  LAYOUT  window,  and  selecting 
"SIMULTANEOUS  * "  The  system  then  prompts  the  user  to  enter  the 
name  of  the  (new)  state  to  be  added  (e.g.,  RECEIVING)  and  then 
the  power  required  by  that  instance  while  operating  in  that  state 
(e.g.,  100  (w) ) .  These  prompts  are  repeated  and  the  user  can  add 
more  than  one  new  state  and  their  corresponding  power.  Typing 
"Enter"  terminates  this  process  of  describing  the  states.  The 
operational  states  can  be  specified  at  the  "type"  object  level 
(e.g.,  115V-RADI0) .  To  do  this,  one  should  start  from  the 
inventory  menu  (where  the  various  type  objects  are  displayed)  and 
proceed  as  described  above. 

To  specify  that  load-instance  115V-RADIO-1  should  not  be 
transmitting  when  its  antenna  ANTENNA-1  is  tracking,  the 
following  procedure  is  followed,  clicking  the  left  button  on  the 
instance  symbol  (displayed  in  the  LAYOUT  window)  and  selecting 
"SIMULTANEOUS"  allows  the  user  to  access  the  "Add  Simultaneous 
Constraint"  selection.  The  user  is  then  presented  with  a  menu  of 
legal  operational  states  that  has  been  specified  for  this  load 
instance  (see  previous  paragraph  on  how  to  do  this).  In  this 
case,  these  are  OFF,  TRANSMITTING,  and  RECEIVING.  The  system  then 
prompts  for  the  other  load  instance  and  the  user  types  in  the 
name  (ANTENNA-1) .  Then,  the  system  presents  the  user  with  all  the 
operational  states  that  have  been  specified  for  this  other  load 
instance  (e.g.,  OFF,  IDLE,  TRACKING).  The  user  can  then  select 
"TRACKING"  to  complete  the  addition  of  the  simultaneous 
constraint. 

Deleting,,, Simultaneous  Constraints-  Deleting  a  simultaneous 
constraint  is  performed  by  clicking  the  left  button  on  a  load 
instance  symbol  (e.g.,  "R"  for  115V-RADI0-1)  that  is  involved  in 
the  constraint,  selecting  "SIMULTANEOUS"  and  then  selecting 
"Delete  Simultaneous  Constraint."  The  user  is  then  presented  with 
a  menu  of  operational  states  that  have  been  described  for  this 
instance.  Once  the  state  (involved  in  the  constraint  to  be 
deleted)  is  selected,  all  the  constraints  associated  with  that 
state  are  displayed  as  a  menu.  The  user  can  select  the  constraint 
to  be  deleted. 

Primary  mower  requirements  calculation.  Calc-max-simultaneous- 
power  is  the  function  that  performs  the  estimation  of  the  maximum 
simultaneous  power  required.  When  called  with  the  name  of  the 
mission  knowledge  base,  it  returns  the  maximum  power  (in  watts) 
that  should  be  allowed  to  meet  the  power  requirements  of  all 
loads  in  the  mission.  It  begins  by  grouping  all  loads  related  by 
a  particular  simultaneous  constraint  together  and  computes  the 
maximum  power  that  would  be  required  by  each  group  under  all 
allowed  combinations  of  loads/states.  All  group  requirements  are 
then  totaled  giving  the  overall  power  requirement. 
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4.5.4  Load  Positioning  and  Distribution  Networking 

Tha  placement  of  loads  and  distribution  boxas  and  thair 
interconnection  uain?  oablaa  is  also  anothar  araa  that  is 
oonsidarad  for  automation  by  tha  LOADMAN  system.  Heuristics  on 
load  placement  like  ’'It  is  weight  and  cost  efficient  to  locate 
heavy  power  consumers  (loads)  close  to  the  power  sources,  thereby 
reducing  or  eliminating  tha  need  for  feeder  systems  and 
additional  cabling,"  would  be  used  to  solve  this  problem. 
Clustering  techniques  which  scan  the  layout  (once  the  loads  have 
been  placed)  to  determine  load  concentration  areas,  can  be  used 
to  determine  the  placement  of  distribution  boxes  so  that  minimum 
oabling  would  be  used  for  maximum  coverage  with  minimum  power 
loss  in  the  cables. 

During  load  positioning  and  networking,  the  proximity  constraints 
are  also  considered  because  they  specify  spatial  conditions  that 
should  be  observed,  like  "MESSAGE-SENDERS  should  not  be  located 
closer  than  20  ft.  to  the  perimeter  of  the  camp." 


Use  of  Proximity  Constraints 

Load  cluster Ina.  Scan-layout  is  a  routine  which  has  been  written 
to  cluster  loads  that  have  been  placed  on  the  campsite.  It 
examines  the  campsite  in  strip-like  sections  (using  a  step-size 
supplied  by  the  user) .  It  scans  two  adjacent  strips  at  a  time 
making  sure  that  load  instances  in  an  adjacent  strip  (but  close 
enough)  are  not  ignored  during  tha  clustering  process.  This 
routine  is  called  by  supplying  a  horizontal  step-size  and  a 
vertical  step-size  which  are  judiciously  selected  based  on  the 
amount  of  standard  cabling  that  is  available.  For  example,  if  the 
desired  cable  length  from  distributors  to  loads  is  50  ft.,  than 
the  length  along  a  diagonal  would  have  to  be  50  ft.  So  the  length 
(and  breadth)  of  reach  that  could  be  attained  by  a  single 
distributor  is  (50  ■+•  1.414) .  Since  a  distributor  could  be  placed 
in  the  center  of  all  the  loads,  the  cluster  size  could  be  twice 
the  length/breadth  reach  (2  x  (50  -i-  1.414))  which  is  approx.  70.7 
ft.  So  a  convenient  step-sizo  would  be  70  ft.  (rounding  from  70.7 
ft.).  This  allows  the  scan-layout  routine  to  divide  the  campsite 
in  70  ft.  x  70  ft.  sections  and  identify  the  clusters  that  fall 
into  such  sections.  Tha  scan-layout  routine  returns  the  cluster 
information  as  a  list  of  lists.  For  example, 

( (TENT-1) 

( OPERATION-CENTER- 1  TENT-2  TENT-3) 

( 115V-RADIO-1  115V-RADIO-2 ) 


etc. 

) 

would  mean  that  TENT-1  is  all  by  itself.  OPERATION-CENTER-1, 
TENT-2,  and  TENT-3  form  another  cluster,  while  115V-RADIO-1  and 
115V-RADIO-2  form  a  third  cluster. 
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flll  Qg  proximity  constraints.  As  mentioned  before  (Ssotion 
4.5.2),  proximity  constraints  spacify  conditions  on  ths  placement 
of  load  instancss.  Ths  ussr  intsrfaos  for  specifying  such 
constraints  is  through  ths  "CURATOR"  sslsction  on  ths  main  menu. 
Ons  of  ths  sslsctions  in  ths  CURATOR  menu  (Figure  5)  is  "Add 
Proxiaity  Constraint."  Whan  this  is  selected,  ths  user  is 
presented  a  aenu  with  ths  choices:  PERIMETER  (for  constraints 
Involving  the  perimeter  of  ths  campsite)  and  LOAD  (for 
constraints  involving  other  load  instances) .  When  "PERIMETER"  is 
selected,  the  user  is  presented  with  a  menu  of  "type"  objects 
(e.g.,  OFFICE-TELEPHONE,  MESSAGE-SENDERS,  eta.).  MESSAGE-SENDERS 
is  selected  to  add  a  constraint  involving  massage-senders.  Next, 
the  user  is  presented  with  a  menu  having  the  following 
selections:  THISOBJECT,  CHILDREN,  PARENTS.  The  user  can  select 
THIdOBJECT  if  the  constraint  is  to  be  applied  across  all 
instances.  For  example,  if  all  message-senders  should  not  be 
placed  closer  than  ,25  ft.  to  the  perimeter,  then  THISOBJECT 
should  be  selected.  On  the  other  hand,  if  the  constraint  applies 
to  only  one  message-sender  (say  MESSAGE-RENDER-l) ,  then 
"CHILDREN"  should  be  selected  to  display  all  the  instances  (in 
the  form  of  a  menu) .  Now  MESSAGE-SENDER-1  can  be  eeleatad  as  the 
only  instance  object  for  which  the  constraint  is  valid. 

Nov  the  user  is  asked  to  enter  the  operator  that  is  to  be 
applied:  <  (less  than)  or  >  (greater  than) .  To  specify  that  the 
MESSAGE-SENDER  cannot  be  closer  than  25  ft.,  the  user  should  type 
<  (less  than).  Next  the  system  prompts  for  the  distance  which  is 
25. 

The  constraint  has  been  specified  and  can  be  used  by  the  system 
while  performing  the  placement.  From  the  CURATOR  menu,  "Delete 
Proximity  constraints"  can  be  selected  for  deleting  any 
previously  specified  proximity  constraint.  As  before,  the 
specific  constraint  type  is  selected  (LOAD  or  PERIMETER)  and  then 
the  particular  object  is  located  (from  the  type  objects  and 
THISOBJECT/CHILDREN/ parents  menu).  Once  the  particular  object  has 
been  identified,  all  proximity  constraints  of  the  selected  type 
are  displayed  in  the  form  of  a  menu.  The  user  may  select  the 
constraint  to  be  deleted. 


4.5.5  Load  Scheduling 

This  feature  of  LOADMAN  is  expected  to  change,  and  hence  it  is 
not  fully  implemented  in  terms  of  the  user  interface  aspects.  The 
basic  idea  of  load  scheduling  is  that  the  user  should  be  able  to 
specify  continuous  and  periodic  loads  that  could  be  allotted 
specific  time  slots  by  the  expert  system.  Thus,  the  user  would 
specify  that  a  particular  load  needed  "5509  watts  every  hour  for 
half-an-hour  throughout  the  entire  mission." 

During  discussions  with  contact  personnel  at  Ft.  Belvoir,  it 
became  obvious  that  the  ability  to  represent  and  use  periodic 
load  specifications  was  not  necessary  as  most  loads  were 
continuous  or  "on-demand."  Hence,  the  emphasis  was  shifted  to 
areas  other  than  load  scheduling.  However,  step  7  and  8  in  the 
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Demonstration/Tutorial  Sheet  (Appendix  A)  explains  the  procedure 
in  detail.  In  short,  planning  of  load  schedules  is  done 
algorithmically  by  matching  p^wor  availability  and  power 
requirement  patterns.  Options  are  generated  for  each  load, 
ranked,  and  the  best  option  is  selected. 
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SECTION  5 


CONCLUSIONS  AND  RECOMMENDATIONS 


Computer  assistance  in  the  areas  of  power  generation  and 
distribution  planning,  and  load  management  is  a  necessary  element 
of  achieving  increased  mission  efficiency  and  reliability  and 
reduced  risk  to  personnel*  The  recommended  way  to  achieve  such 
computerization  is  by  the  use  of  an  expert  system  designed  so 
that  it  operates  well  under  normal  as  well  as  adverse  conditions. 
Under  adverse  conditions  it  should  be  able  to  maintain  a  level  of 
performance  that  is  as  good  as  the  operating  conditions  will 
allow.  In  suah  situations  the  system  may  have  to  drop  some  loads 
or  operate  other  loads  at  reduced  power,  since  these  decisions 
could  have  major  ramifications  on  mission  success,  the  system 
will  have  to  be  designed  according  to  well-defined  Army  policies 
and  procedures. 


5 . 1  CONCLUSIONS 

TAI  has  investigated  the  feasibility  of  applying  expert  systems 
technology  to  generator-based  power  systems  management.  Based  on 
its  initial  research  effort  in  this  area,  the  project  team  found 
that  the  use  of  such  technology  is  indeed  feasible  and  that  its 
potential  benefits  are  considerable. 

Some  conclusions  from  Phase  I  are: 

1.  some  kind  of  action  is  necessary  to  keep  the  power 
generation  and  distribution  systems  operating  efficiently, 
reliably,  cost  effectively,  and  safely  and  to  reduce 
damage  to  equipment. 

2.  Expert  systems  technology  is  appropriate  for  building  a 
computer-based  planning  and  control  system  to  achieve  the 
above  purpose.  The  flexibility  of  expert  system  techniques 
in  handling  variations  of  a  problem  (different  types  of 
missions,  failure  scenarios,  etc.)  is  a  definite 
advantage . 

3.  Object-oriented  programming  techniques  (a  part  of  expert 
systems  technology)  enhance  the  flexibility,  extend- 
ibility,  and  maintainability  of  the  system. 

4.  Heuristics  specific  to  a  particular  mission  are  easily 
included. 

5.  The  proposed  technology  and  methods  promote  modular  system 
development  and  incremental  development/ implementation. 
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5.2  RECOMMENDATIONS 


Arriving  at  tha  above-mentioned  conclusions,  ths  pro j sot  tsam 
worked  on  che  conceptual  design  of  Phase  II  activities.  Section  3 
of  this  report  incorporates  the  results  of  this  effort.  The 
project  team  also  formulated  the  following  recommendations: 

1.  Plans  for  Phase  II  development  are  discussed  and  the 
expectations  are  realistic.  The  final  system  will  be 
beneficial  to  Army  units  in  many  ways. 

2.  However,  a  number  of  steps  described  in  the  report  (see 
Seotion  2,  "Domain  Analysis  and  Findings")  must  be  taken 
to  successfully  develop  and  deploy  the  envisioned  system. 

o  A  body  of  knowledge  should  be  formed  that  is  derived 
from  the  theory  of  power  generation  and  distribution 
systems.  This  is  necessary  because  the  current  domain 
does  not  have  an  expert  who  is  substantially  better  at 
solving  the  problem (s)  (as  gathered  from  Army  comments 
and  reports) . 

o  Standard  practices,  in  the  areas  of  load  shedding  and 
load  scheduling,  should  be  established  which  aould  then 
be  followed  and  monitored  to  ensure  the  safe  and 
reliable  operation  of  power  distribution  systems.  This 
is  important  because  it  is  impossible  to  design  a 
decision-making  system  without  a  definite  idea  of  what 
decisions  are  desirable  under  specif ic  circumstances. 

o  Development  of  the  LOADMAN  expert  system  should  be 
performed  in  two  stages  -  planning  (off-line),  and 
monitoring  and  control  (on-line) . 

3.  Stage  I  should  concentrate  on  specifying  equipment, 
establishing  policies  and  procedures  for  baakup  equipment, 
and  establishing  priorities  for  the  various  loads.  Then 
tha  system  should  be  built  to  plan  inventory  requirements, 
configure  the  equipment,  perform  load  shedding  when 
necessary,  and  perform  duty  cycle  scheduling  for  heavy 
periodic  loads.  Thus,  Stage  I  would  result  in  an  off-line 
advisory  system  that  will  be  very  useful  in  its  own  right. 

4.  Stage  II  should  extend  the  system  built  in  Stage  I  to 
produce  an  on-line,  autonomous  system  that  performs  system 
monitoring,  load  management,  and  control.  New  hardware  in 
the  form  of  sensors  and  control  circuits  would  be  required 
at  this  stage  to  make  thw  expert  system  as  autonomous  as 
is  practical. 

The  LOADMAN  project  offers  a  significant  opportunity  to 
successfully  implement  an  on-line  expert  system  that  can  handle 
power  generation  and  distribution  problems.  While  further 
resolution  of  many  questions  is  required,  the  completed  work  in 
Phase  I  clearly  demonstrates  that  additional  work  in  this  area  is 
highly  desirable  and  would  provide  major  '.^onefits. 
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APPENDIX  A 


LOADMAN  Demonstration/Tutorial  Sheet 


1. 

Load 

KEYSTONE  as  normal 

2. 

Load 

LoadMan: 

2.1 

(CD  11 C :  \\LOADMAN " )  *  or  "P:"  if  on  network 

2.2 

(LOAD  ' LOADLM) 

2.3 

(LOAD- LOADMAN) 

3. 

Load 

mission  DEMO: 

3.1 

start  mouse  if  not  already  started  (press  <F1>) 

3.2 

Left-button  on  LoadMan  window 

3.3 

Choose  "Load  Mission" 

3.4 

Choose  "DEMO"  from  list  of  missions 

4.  After  loading,  explain  screen: 

4.1  LoadMan  Window  —  upper  right  oorner  of  screen 
Left-button  on  this  window  to  show  Main  options. 

Create  Mission  ; Creates  new  mission 

Delete  Mission  i Clears  mission  from  memory 

Load  Mission  i Loads  mission  from  disk 

Save  Mission  7  Saves  mission  to  disk 

Show  Inventory  j Displays  the  Inventory  Menu 

Change  Active  Mission  t Changes  the  currently  active 

mission  (for  multiple 
missions  in  memory 
simultaneously) 

4.2  Typescript  Window  —  Blue  4-  or  5-line  window: 

User  entry,  error  messages. 

4.3  Prompt  Window  --  Grey  1-line  window  at  bottom: 

Prompts  for  user  entry,  explanation  of  processing 


Final  Report 


A-l 


August  10,  1988 


4 


5.  Explain  mission  sorssn; 


5.1  Layout  Window:  Shows  ooarss  visw  of  oamp  layout,  and 
component  interaction.  Grey  pan  bars  show  X  &  Y  limits 
of  screen  in  feet. 

5.2  Zoom  Window:  Shows  detailed  view,  with  limited 
component  interaction.  "Zoomed"  location  (in  feat)  is 
shown  in  title  of  Layout  Window.  The  actual  area  is 
highlighted  in  the  Layout  Window. 

5.3  Inventory  Menu  (may  have  to  left  button  on  the  LOADMAN 
icon  to  show)  shows  all  known  mission  component  types, 
the  current  count  used  in  this  mission,  and  the 
specified  maximum  number  which  can  be  used  in  this 
mission. 


6.  Exercise  system: 

6.1  Layout  Window: 

6.1a  Item  Explanation 

ainaltt  -item i 

Left  button  on  a  G  to  display  explanation  about  the 
Generator  in  a  temporary  window.  Click  anywhere  to 
make  it  go  away. 

QyiElflBalng-,  itamfli 

A  "+"  indicates  overlapping  items  or  items  that  are  so 
close  that  they  cannot  be  displayed  separately  with 
the  resolution  of  the  particular  screen. 

Left  button  on  a  "+"  to  display  a  list  of  overlapping 
items.  Choose  one  for  explanation.  Click  anywhere  to 
make  it  go  away. 

6.1b  Moving  the  Zoom  window 

Right-button  inside  Layout  window  and  the  Zoom  window 
will  move  to  that  location.  Any  items  inside  the 
region  will  be  displayed  in  the  Zoom  window. 

6.1c  Scrolling  Layout  Window 

WILL  NOT  SCROLL  OFF  QL  .S&MP. 

So.  layout  mav  not  react  when  you  are  on  an  edge 
Right  button  on  left  border.  ? Scroll  South 
Left  button  on  left  border.  > scroll  North 

Right  button  on  bottom  border.  /Scroll  East 
Left  button  on  bottom  border.  /Scroll  West 
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6.2  Zoom  Window! 

6.2a  Itam  Explanation 

Left-button  to  explain  item  (single/ overlapping 
items) .  Same  as  in  Layout  window. 

6.2b  Moving  the  zoom  window  in  the  layout  window 
Left  button  on  left  border.  ;Move  North 
Right  button  on  left  border.  ;Move  South 

Left  button  on  bottom  border.  >Mova  West 
Right  button  on  bottom  border.  ;Movc  East 

6.3  Inventory  Menu: 

6.3a  Add  an  item 

Left  button  on  an  item  type  (TELEPHONES) 

Cliak  on  ADD  when  the  menu  appears. 

Position  item  in  the  layout  window  by 

clicking  left  button  at  desired  location. 
Position  item  in  the  zoom  window  by  clicking 
at  deaired  location. 

6.3b  Dalfifc*  an  item 

Left  button  on  an  item  type  (TELEPHONES) 

Choose  DELETE  when  the  menu  appears. 

Choose  specific  instance  (highest  numbered 
instance  -  the  one  you  just  added) . 

6.3c  Move  item  to  a  different  location 

-  doesn't  work  yet 

6.3d  Zoom 

-  doesn't  work  yet 

6.3e  Delate 

-  doesn't  work  yet 

6.3f  Display  a  class  item  (SKIP  THIS  FOR  non-AJ. UJftfiUtl 
Left  button  on  an  item  type  in  the  Inventory  menu. 
Show  slot  comments,  bring  up  child  instances,  eto. 

6.3g  Change  Maximum 

Left  button  on  an  item  type  (TELEPHONES) 

Choose  MAXIMUM  when  the  menu  appears. 

Enter  the  maximum  number  of  instanoes  allowed  (4). 
Show  that  the  maximum  number  (on  the  inventory 
menu)  for  telephones  is  04  instead  of  00. 

At  this  point  the  number  of  telephone  instances  in 
the  mission  is  4  (the  max  allowed) . 

Try  creating  a  telephone  (use  ADD  -  6.3a). 
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Demonstrate  Schedul ing : 

7.1  (mode  6)  ;Go  to  tha  graphloa  scraan. 

(Generate-schedule  'demo) 

Upper  window  shows  Power  Used 
Lower  window  shows  Power  Required  by  load 
being  scheduled 

Display  BLACKBOARD  object  in  Kb  DEMO. 

Show  FAILED-LOADS  slot  to  show  that  some  loads  were 
not  scheduled. 

You  can  also  display  Power  Available  in  the  upper 
window 

To  do  this,  get  to  the  DISPLAY-GRAPH  slot  on  tha 

BLACKBOARD  object  (being  displayed)  and  change  the 
value  to  T. 

(Gsnerate-schedule  'demo) 

Show  load  requirements  specification: 

8.1  Display  120-V-RADI0-1  object  and  get  to 
POWER-NEEDED  Slot. 

VALUE:  (5509  0  3600  1800  3600) 

Hart  the  first  number,  5509  (Watts)  is  the  power 
ne*4ed  for  that  load.  0  is  the  start-time  within  each 
period  and  3600  (1  hr)  is  the  end-time  within  each 
period.  1800  (1/2  hr)  is  the  duration  for  which  the 
loid  must  be  scheduled.  And  the  last  3600  (l  hr) 
denotes  the  period. 

So  the  radio  will  be  scheduled  every  hour  for  a  half 
hour  anywhere  within  the  hour. 

8.2  Get  to  tha  SCHEDULED  slot  to  show  how  this  was 
scheduled. 

VALUE:  (0  3600  7600  ...) 

H«re  we  can  see  that  the  radio  was  scheduled  at  0 
secs,  3600  secs  (1  hr),  and  again  at  7600  secs  etc. 

8 . 3  Show  the  power  needed  as  a  graph  . . . 

(SCALING 

X  axis:  0  -  all  .of  mission 
Y_axla:  0  -  max-Powar  available  :  Now  60KVn 
(Graph-load  '120-V-RADIO-l)  /Graphing  a  periodic  load 
Click  left  button  to  close. 

(Graph-load  '50-MAN-TENT-l)  /Graph  of  a  continuous 
load 

Click  left  button  to  close. 
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